Received-SPF: pass (google.com: domain of linux-kernel+bounces-89121-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Fri, 1 Mar 2024 12:51:17 -0800
From: Dan Williams <dan.j.williams@intel.com>
To: Ira Weiny <ira.weiny@intel.com>, Dan Williams <dan.j.williams@intel.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>, Smita Koralahalli
	<Smita.KoralahalliChannabasappa@amd.com>, Shiju Jose <shiju.jose@huawei.com>
CC: Dan Carpenter <dan.carpenter@linaro.org>, Yazen Ghannam
	<yazen.ghannam@amd.com>, Davidlohr Bueso <dave@stgolabs.net>, Dave Jiang
	<dave.jiang@intel.com>, Alison Schofield <alison.schofield@intel.com>,
	"Vishal Verma" <vishal.l.verma@intel.com>, Ard Biesheuvel <ardb@kernel.org>,
	<linux-efi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-cxl@vger.kernel.org>, Ira Weiny <ira.weiny@intel.com>, "Rafael J.
 Wysocki" <rafael@kernel.org>, Tony Luck <tony.luck@intel.com>, "Borislav
 Petkov" <bp@alien8.de>
Subject: Re: [PATCH 2/4] acpi/ghes: Process CXL Component Events
Message-ID: <65e23fc5402c1_3651e29483@dwillia2-mobl3.amr.corp.intel.com.notmuch>
References: <20240228-cxl-cper3-v1-0-6aa3f1343c6c@intel.com>
 <20240228-cxl-cper3-v1-2-6aa3f1343c6c@intel.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20240228-cxl-cper3-v1-2-6aa3f1343c6c@intel.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?yR9FjFEo5H+XUb2eRODQSqt/SO+bSWznoP8sex7lSRsS1cV9jzn/YECdosNn?=
 =?us-ascii?Q?OQicfAnr4xhZ/UZBeQ39ZE5HTDy0vQvYKR+EEqKTV1VJMgw1tMnrX13hRY+o?=
 =?us-ascii?Q?ia015Pw2EK6hDiLpstC3c5mR/EW6Sw34KeJ8XMtVNMt9DuBVDVKGEVUypBEa?=
 =?us-ascii?Q?A1NbJyatPt/7HDaYceKC6uqJEIpMJBKAf6efRUuwF9CR6GxK0IVqy2Mby+Yq?=
 =?us-ascii?Q?zegNuIE2i92t/x229qhatJSV4l42yfiwG+dy5hnXRWTx0Zr9Ecz6fKUKhXLJ?=
 =?us-ascii?Q?EjMHGvF/tU0dKhqxjpy63K/e/a3VQ5GhnSuMxHYaGwaaQVHqwfW+ZbzuLbKe?=
 =?us-ascii?Q?vFChp3b2TkrzOsdimidfmrIvngQ+ixOwjQxfw3Lpv9FeT1CEMUx503NsSu1U?=
 =?us-ascii?Q?ZfLYG03vUm1cfanPAWy8G4eDYP+dnA/C0F3sU0sqvZJyaovbH2DAsFxhrA06?=
 =?us-ascii?Q?AXJJ2IrFbkDot2vhvMxzFdBSXkHBlNwKIP5GOZUewyCWm59FZ/XkrLIcmyXP?=
 =?us-ascii?Q?QXEHMM7aadEoWhyw4j0zklJh0bucHNp2usEmWWKxenrp5bdsl4doJhXueoRP?=
 =?us-ascii?Q?XTROB0JFLoVOPbsCLP49yAcw1R74SaEDtItni0oHtnUaYTzWKEYGFQ7oR5S2?=
 =?us-ascii?Q?yLpXKM7ig+TUMvqnBzqOQsxfzc2h1eMr5npkKDWK0d2PZsGao30pNCOW/zgM?=
 =?us-ascii?Q?1trjHbNDBUhnqDjXK+lPsbjqtVzJcL9jqH7j/QrMuJPopWLTCqVePCsXyv6T?=
 =?us-ascii?Q?lmCFvCbyAq1E987Sc8lPTI7zvx8IHE8HbYeA25KbvsbM3Ggp0iGLkQU4uU3N?=
 =?us-ascii?Q?8Bo587zau1pBxuC8E2x5nY/mIAUtiKqC25FVcYb9RHxgYjrj7vMuS/0Hx8N5?=
 =?us-ascii?Q?1pjIC9KhKFAqGNA2bwYpJUBpCni6w0tCzaq/WuWQOsyWzczXfvuhCdDrs+AN?=
 =?us-ascii?Q?1PoBl88AVPwtRC3JGjUOrPvtlr3rvA5Y7z/ieCKPfLz+WFbR7usMKNV+m3zs?=
 =?us-ascii?Q?tb6g8Ovis/03j+BeVpjlwQpkf028XSew7UviXKqH7bwMZHtpJ/Xzniy+5Qe9?=
 =?us-ascii?Q?3/y+faH+sCgOZitDpegxC93rkYwOscRLw0zK+U8gP36Oz67xZPUvLYLQsOUd?=
 =?us-ascii?Q?f8WQn8gs6C5JcWIDLQ01QEc/Y88whNHvnWGEMCm8dIU5MEqKApL6+V07MkwI?=
 =?us-ascii?Q?dkYZPz5GjdxDLmlo9ZaUj90fmPrsmqvxuMfkfsM+AVcRLAWk2tmJ8Q9pPqKw?=
 =?us-ascii?Q?YeuwdcVxwBTJyYzxZkiYv4uPWV2H8+5hqR+g5V5rY5vIq4TJxCs/RpIqaoXI?=
 =?us-ascii?Q?u+y4bhL6g4gtzeJ4cu5YVAcA/eTTmO154pUerj4epvlTIDO9+qyEjGx8npwe?=
 =?us-ascii?Q?kaxWoPUUeDXkVZBzX8X1lU+lpqk2l1+I0dEI4aXWajE9ebUxzCzzIcBu6fTv?=
 =?us-ascii?Q?1Xln9/j4CWnh/S80O/kIOy/Pehte0Urc4DBma0P5RImuGlgTqrdRj/a4JPJV?=
 =?us-ascii?Q?hzIcCXTaTXwDquszXWWNEHS45UiE67c1A9FjSUKWobv4qy+UaAch8zmL3zyq?=
 =?us-ascii?Q?c40OQ+ghRhBRJB4bXt5vlGydEOWDA1LS3aD34ePk/ANqqtl3ZNsqME62kHed?=
 =?us-ascii?Q?lQ=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: bd0b4746-c73a-423d-0e8e-08dc3a3158f5
X-MS-Exchange-CrossTenant-AuthSource: PH8PR11MB8107.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2024 20:51:20.1851
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: hMP+r8TQMfjyF4xwOYI09ADAA8D5OEwDxOYDrENuuyWAi7GsXU0xpMGbp+l7Bt1NcemwCNiVsi+KMFwDQ4sAu+Np3xl7o/ktqkAQHLsblAw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB7698
X-OriginatorOrg: intel.com

Ira Weiny wrote:
> BIOS can configure memory devices as firmware first.  This will send CXL
> events to the firmware instead of the OS.  The firmware can then send
> these events to the OS via UEFI.  Currently a configuration such as this
> will trace a non standard event in the log.  Using the specific CXL
> trace points with the additional information CXL can provide is much
> more useful to users.  Specifically, future support can be added to CXL
> provide the DPA to HPA mapping configured at the time of the event.

One could argue that support should have happened first and taken the
event all the way to EDAC, so this needs to merged on faith that that
those patches are in flight.

> UEFI v2.10 section N.2.14 defines a Common Platform Error Record (CPER)
> format for CXL Component Events.  The format is mostly the same as the
> CXL Common Event Record Format.  The difference is the use of a GUID in
> the Section Type rather than a UUID as part of the event itself.
> 
> Add GHES support to detect CXL CPER records and call into the CXL code
> to process the event.
> 
> Multiple methods were considered for the call into the CXL code.  A
> notifier chain was considered for the callback but the complexity did
> not justify the use case.

Not sure what this adds. If you want to talk about alternatives and
tradeoffs, great, but that should be a comparative analysis in support
of the chosen direction.

> Furthermore, the CXL code is required to be called from process
> context as it needs to take a device lock so a simple callback
> register proved difficult.  Dan Williams suggested using 2 work items
> as an atomic way of switching between a callback being registered and
> not.  This allows the callback to run without any locking.[1]
> 
> Note that a local work item is required to dump any messages seen during
> a race between any check done in cxl_cper_post_event() and the
> scheduling of work.  That said, no attempt is made to stop the addition
> of messages into the kfifo because this local work item provides a hook
> to add a local CXL CPER trace point in a future patch.
> 
> This new combined patch addresses the report by Dan Carpenter[2].  Thus
> the reported by tag.
> 
> [1] https://lore.kernel.org/all/65d111eb87115_6c745294ac@dwillia2-xfh.jf.intel.com.notmuch/
> [2] https://lore.kernel.org/all/b963c490-2c13-4b79-bbe7-34c6568423c7@moroto.mountain/
> 
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Tony Luck <tony.luck@intel.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>

checkpatch will whine about a missing Closes: tag.

> Suggested-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Ira Weiny <ira.weiny@intel.com>
> 
> ---
> [djbw: use kfifo for record data]
> [djbw: Use work struct for sync between cxl reg and ghes code]
> ---
>  drivers/acpi/apei/ghes.c  | 127 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/cxl-event.h |  18 +++++++
>  2 files changed, 145 insertions(+)
> 
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index ab2a82cb1b0b..f433f4eae888 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -26,6 +26,7 @@
>  #include <linux/interrupt.h>
>  #include <linux/timer.h>
>  #include <linux/cper.h>
> +#include <linux/cxl-event.h>
>  #include <linux/platform_device.h>
>  #include <linux/mutex.h>
>  #include <linux/ratelimit.h>
> @@ -33,6 +34,7 @@
>  #include <linux/irq_work.h>
>  #include <linux/llist.h>
>  #include <linux/genalloc.h>
> +#include <linux/kfifo.h>
>  #include <linux/pci.h>
>  #include <linux/pfn.h>
>  #include <linux/aer.h>
> @@ -673,6 +675,116 @@ static void ghes_defer_non_standard_event(struct acpi_hest_generic_data *gdata,
>  	schedule_work(&entry->work);
>  }
>  
> +/* CXL Event record UUIDs are formated as GUIDs and reported in section type */
> +
> +/*
> + * General Media Event Record
> + * CXL rev 3.0 Section 8.2.9.2.1.1; Table 8-43
> + */
> +#define CPER_SEC_CXL_GEN_MEDIA_GUID					\
> +	GUID_INIT(0xfbcd0a77, 0xc260, 0x417f,				\
> +		  0x85, 0xa9, 0x08, 0x8b, 0x16, 0x21, 0xeb, 0xa6)
> +
> +/*
> + * DRAM Event Record
> + * CXL rev 3.0 section 8.2.9.2.1.2; Table 8-44
> + */
> +#define CPER_SEC_CXL_DRAM_GUID						\
> +	GUID_INIT(0x601dcbb3, 0x9c06, 0x4eab,				\
> +		  0xb8, 0xaf, 0x4e, 0x9b, 0xfb, 0x5c, 0x96, 0x24)
> +
> +/*
> + * Memory Module Event Record
> + * CXL rev 3.0 section 8.2.9.2.1.3; Table 8-45
> + */
> +#define CPER_SEC_CXL_MEM_MODULE_GUID					\
> +	GUID_INIT(0xfe927475, 0xdd59, 0x4339,				\
> +		  0xa5, 0x86, 0x79, 0xba, 0xb1, 0x13, 0xb7, 0x74)
> +
> +struct cxl_cper_work_data {
> +	enum cxl_event_type event_type;
> +	struct cxl_cper_event_rec rec;
> +};
> +
> +DEFINE_KFIFO(cxl_cper_fifo, struct cxl_cper_work_data, 32);
> +static DEFINE_SPINLOCK(cxl_cper_read_lock);
> +static DEFINE_SPINLOCK(cxl_cper_write_lock);
> +
> +static cxl_cper_callback cper_callback;
> +/* cb function dumps the records */
> +static void cxl_cper_cb_fn(struct work_struct *work)
> +{
> +	struct cxl_cper_work_data wd;
> +
> +	while (kfifo_out_spinlocked(&cxl_cper_fifo, &wd, 1,
> +			&cxl_cper_read_lock)) {

Why is this taking the lock on retrieval? The work item is
single-threaded. The only potential contention is between
cxl_cper_local_fn() and cxl_cper_cb_fn() collision, but that can be
handled by a cancel_work_sync(&cxl_local_work) on registration to pair
with the cancel_work_sync(&cxl_cb_work) on unregistration.

..but I am not sure 2 work items are needed unless some default
processing is going to happen in the "local" case.

> +		cper_callback(wd.event_type, &wd.rec);
> +	}
> +}
> +static DECLARE_WORK(cxl_cb_work, cxl_cper_cb_fn);
> +
> +static void cxl_cper_local_fn(struct work_struct *work)
> +{
> +	struct cxl_cper_work_data wd;
> +
> +	while (kfifo_out_spinlocked(&cxl_cper_fifo, &wd, 1,
> +			&cxl_cper_read_lock)) {

This just looks like open coded / less efficient kfifo_reset_out().

> +		/* drop msg */

If the proposal is to do nothing when no callback is registered then no
need to have have cxl_local_work at all.

> +	}
> +}
> +static DECLARE_WORK(cxl_local_work, cxl_cper_local_fn);
> +
> +/* Pointer for atomic switch of record processing */
> +struct work_struct *cxl_cper_work = &cxl_local_work;
> +
> +static void cxl_cper_post_event(enum cxl_event_type event_type,
> +				struct cxl_cper_event_rec *rec)
> +{
> +	struct cxl_cper_work_data wd;
> +
> +	if (rec->hdr.length <= sizeof(rec->hdr) ||
> +	    rec->hdr.length > sizeof(*rec)) {
> +		pr_err(FW_WARN "CXL CPER Invalid section length (%u)\n",
> +		       rec->hdr.length);
> +		return;
> +	}
> +
> +	if (!(rec->hdr.validation_bits & CPER_CXL_COMP_EVENT_LOG_VALID)) {
> +		pr_err(FW_WARN "CXL CPER invalid event\n");
> +		return;
> +	}
> +
> +	wd.event_type = event_type;
> +	memcpy(&wd.rec, rec, sizeof(wd.rec));

Unfortunate to have a double copy of the record into the stack variable
and then again into the kfifo, but I can not immediately think of a way
around that.

> +
> +	kfifo_in_spinlocked(&cxl_cper_fifo, &wd, 1, &cxl_cper_write_lock);
> +	schedule_work(cxl_cper_work);

I think you don't need 2 work items if you write it this way:

        spin_lock_irqsave(&cxl_cper_write_lock, flags);
        if (cxl_cper_work) {
                if (kfifo_put(&cxl_cper_fifo, &wd))
                        schedule_work(cxl_cper_work);
                else
                        pr_err_ratelimited(
                                "buffer overflow when queuing CXL CPER record\n");
        }
        spin_lock_irqrestore(&cxl_cper_write_lock, flags);

..and then take the write lock when modifying that cxl_cper_work
pointer between NULL and non-NULL.