From patchwork Wed Jul 12 19:59:01 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Elliott Mitchell X-Patchwork-Id: 13310855 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 910E2EB64DA for ; Wed, 12 Jul 2023 20:03:01 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.562749.879541 (Exim 4.92) (envelope-from ) id 1qJg2q-00047m-MM; Wed, 12 Jul 2023 20:02:40 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 562749.879541; Wed, 12 Jul 2023 20:02:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qJg2q-00047f-Jf; Wed, 12 Jul 2023 20:02:40 +0000 Received: by outflank-mailman (input) for mailman id 562749; Wed, 12 Jul 2023 20:02:39 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qJg2o-00047T-VS for xen-devel@lists.xenproject.org; Wed, 12 Jul 2023 20:02:38 +0000 Received: from mailhost.m5p.com (mailhost.m5p.com [74.104.188.4]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 0a4cf889-20ef-11ee-8611-37d641c3527e; Wed, 12 Jul 2023 22:02:35 +0200 (CEST) Received: from m5p.com (mailhost.m5p.com [IPv6:2001:470:1f07:15ff:0:0:0:f7]) by mailhost.m5p.com (8.16.1/8.15.2) with ESMTPS id 36CK2IJs091884 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 12 Jul 2023 16:02:24 -0400 (EDT) (envelope-from ehem@m5p.com) Received: (from ehem@localhost) by m5p.com (8.16.1/8.15.2/Submit) id 36CK2IMq091883; Wed, 12 Jul 2023 13:02:18 -0700 (PDT) (envelope-from ehem) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 0a4cf889-20ef-11ee-8611-37d641c3527e Message-Id: From: Elliott Mitchell To: xen-devel@lists.xenproject.org Cc: Jan Beulich Cc: Andrew Cooper Cc: =?unknown-8bit?b?IlJvZ2VyIFBhdSBNb25uw6kiIDxyb2dlci5wYXVAY2l0cml4LmNv?= =?unknown-8bit?b?bT4=?= Cc: Wei Liu Date: Wed, 12 Jul 2023 12:59:01 -0700 Subject: [PATCH v3 0/3] Fixing ACPI error reporting display This series has been seen previously. The issue is pretty simple, if ACPI errors occur there is a high probability they will occur on multiple cores at once. Since there is no locking for `printk()` there is a need to emit the entire error with a single `printk()`. I believe this is roughly where things left off. The loop adjustment had been requested to be broken into a separate step. I had also goofed when adjusting the handling and the string order had gotten reversed. I'm unsure how best to make the `printk()` more maintainable. Yet more "%s" and entries[#] will be needed if additional bits get defined. I'm inclined to keep the string broken apart to hint as to how it matches the entry list. I'm okay with everything being fully concatenated if that is felt best. Elliott Mitchell (3): x86/APIC: include full string with error_interrupt() error messages x86/APIC: modify error_interrupt() to output using single printk() x86/APIC: adjustments to error_interrupt() loop xen/arch/x86/apic.c | 32 +++++++++++++++++--------------- 1 file changed, 17 insertions(+), 15 deletions(-)