Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Tue, 31 Oct 2023 09:46:22 -0700
From:   Ira Weiny <ira.weiny@intel.com>
To:     Dan Williams <dan.j.williams@intel.com>,
        Ira Weiny <ira.weiny@intel.com>,
        Jonathan Cameron <jonathan.cameron@huawei.com>,
        Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
CC:     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>
Subject: RE: [PATCH RFC v2 2/3] firmware/efi: Process CXL Component Events
Message-ID: <65412f5defc6d_2e75b2948@iweiny-mobl.notmuch>
References: <20230601-cxl-cper-v2-0-314d9c36ab02@intel.com>
 <20230601-cxl-cper-v2-2-314d9c36ab02@intel.com>
 <653ad3f9d3711_780ef29495@dwillia2-xfh.jf.intel.com.notmuch>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <653ad3f9d3711_780ef29495@dwillia2-xfh.jf.intel.com.notmuch>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?5otri0J1UyU8chWYXOVGPqwUTvhqiqK7TboYe2IQVmnSzjQuSg+d96NDGBHU?=
 =?us-ascii?Q?/4JzJDpuRjkpIjLFFqtNdn6kGuZZvh2jHKQtvQ6YAuifZlITTo/VzhN5D+aW?=
 =?us-ascii?Q?Qyp8tteAvp4aKXI94WJCv4CqgP7vbkRrO7U2y+6k7Hb52eamY2YkdT39ADcN?=
 =?us-ascii?Q?+BwBl6VhetLY4ObSDHwuUvGWWjiaAXsaOymAr81Ak2WHDL1fY2kKpRx0hgLb?=
 =?us-ascii?Q?14VxQoUOJ0CAS2LvVGb2QuAfR4LRoCerHCaUT4kz8/Ze7se5eR8r/iquOm7y?=
 =?us-ascii?Q?zVF5pv6dhHjBnlQb0VT0jjxc5QyN23zYgKQ88YX3uLL6shS3YKlKx8soXVk9?=
 =?us-ascii?Q?VT0W+2e6eLFkHYm9tPr4XDPBR2ON52aAfq4dyXvwKRlm79EV4kxT9DTJnwaP?=
 =?us-ascii?Q?xMOnIu05NOGYRdCEcxjTXVxk/F4x2YXC36n7OFs/JAaO72F6k4pMenjSLhc0?=
 =?us-ascii?Q?5/E59K+srQefmBkfZXLnCKqXpoiOJtnmojSPDyCX+Mj/l4z3q/fdQz0e9d/f?=
 =?us-ascii?Q?RcQCwExk21aW5LozxxViJSjY35YCd4EqVWEcVGCzphUrVE0nlc2j/mnuBs+5?=
 =?us-ascii?Q?fCzOYvi5iOUvQjpxI15Zd8SOeWAQuVc2zIKGm/jyApdKYXsqhZ3O1AEK/SVd?=
 =?us-ascii?Q?hPSvL+Bq8vyJURAXOsZ/rhHs2+3WBYc1ndlJaD4e4m73JJ4YnqFt0qLm0gMW?=
 =?us-ascii?Q?O2efoT3wjiIcIIPjNwxFk6JOJR8gTbRqaRtlQj18+JmmK4iw65VFLpjixH8G?=
 =?us-ascii?Q?px9njBm1np9hYQlMU3JkMa53cG6ZcKszj0Ttzfn/ot5PnDQMEnrgV0j5KUUB?=
 =?us-ascii?Q?Vs4+Aa83gWCRBqTFlYBp5a396jolzPnsdKXxNjuzfKab8A7g+Me1F5wDS0xe?=
 =?us-ascii?Q?fZ2M9Sxn6OKpvZNyIve26xVeo4VCEh93GDDLmD3WizLjBNc6BgaLAeKbO5kq?=
 =?us-ascii?Q?/wLDKV/QoEpi8hSW+w+1yKt4CHyS1UayKRAQD2BV3c2YE18DaghG+OrVKQmT?=
 =?us-ascii?Q?DHLx8Q+S1ho9/4V6JIiBTyFZDpjJ2qI2QibokT8itUVNOucsT38q/KRXFG7Y?=
 =?us-ascii?Q?DNKaJ4Ge65aVxkwB2/W1W2TuSF2ND5saiOVupGbzw/i8/PCechakh6I+NF/U?=
 =?us-ascii?Q?hYVgZREhMG4iZXQtpXK2MTXAzxRBntOYok5AFwQ4TfH4GeG4Z8TcROOw5Wf6?=
 =?us-ascii?Q?8lCtYGmE5Yw8AlFY/9UfF90KzjTYZL4y/4QZUSeMXkviGGm+lkKTzlhB9nhW?=
 =?us-ascii?Q?ORQswzNLbXwED9uh3P3tv56wqsO7QRMv1znLrupWIDRc9E/gLgzL2SkoCClT?=
 =?us-ascii?Q?lkobmWstpNS54qjvtZpvmyeS9FLetqrYSkVxGBzgOo2aNoilA4gbCyEa4xw3?=
 =?us-ascii?Q?9kaotACj2pwzm9lQXJOet7d5sQm27tAV0dSkPQKwdhXukQEJz3Wlx6z3AixG?=
 =?us-ascii?Q?jOa+Xyp09SVSJzHb9JV8QUDrrVMztxr3LMP4Gv5jpN4arnba8DXxKbobpch8?=
 =?us-ascii?Q?rTEEboqvwBN4p3ypI2ZSVXQ44D90sRJvjC7h6KUqxI+fNpuMTOeFQ7Fmm6KI?=
 =?us-ascii?Q?yRwVV9RDObJHe5vyCam6RbWlCRsBIujFpjD7ZpiH?=
X-MS-Exchange-CrossTenant-Network-Message-Id: cc601715-86eb-424d-c615-08dbda30ec0a
X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB6733.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2023 16:46:25.8330
 (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: xBdvo4HtJLz3AxXLMGBA90NH1zeovTBeL9duOKXx2penLmpGZq1sHdIEX9uFSpCTaUHIhq41GZo/LE+AVenIwg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR11MB6967
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-1.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Tue, 31 Oct 2023 09:47:50 -0700 (PDT)

Dan Williams wrote:
> Ira Weiny wrote:

[snip]

> > 
> > diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> > index 35c37f667781..d6415c94d584 100644
> > --- a/drivers/firmware/efi/cper.c
> > +++ b/drivers/firmware/efi/cper.c
> > @@ -607,6 +607,22 @@ cper_estatus_print_section(const char *pfx, struct acpi_hest_generic_data *gdata
> >  			cper_print_prot_err(newpfx, prot_err);
> >  		else
> >  			goto err_section_too_small;
> > +	} else if (guid_equal(sec_type, &CPER_SEC_CXL_GEN_MEDIA) ||
> > +		   guid_equal(sec_type, &CPER_SEC_CXL_DRAM) ||
> > +		   guid_equal(sec_type, &CPER_SEC_CXL_MEM_MODULE)) {
> > +		struct cper_cxl_event_rec *rec = acpi_hest_get_payload(gdata);
> > +
> > +		printk("%ssection type: CXL Event\n", newpfx);
> 
> I would say that since this is going to be hanlded elsewhere the kernel
> log can stay silent.

Yep, bad cargo cult.

Removed.

[snip]

> > +
> > +int register_cxl_cper_notifier(struct notifier_block *nb)
> > +{
> > +	return blocking_notifier_chain_register(&cxl_cper_chain_head, nb);
> > +}
> > +EXPORT_SYMBOL(register_cxl_cper_notifier);
> 
> I think this should be EXPORT_SYMBOL_NS_GPL(..., CXL) since I can't
> imagine a third-party driver use case for this.

Good point.  Done.

[snip]

> >  
> > +/*
> > + * Event log size adjusted for CPER
> > + *
> > + * Base table from CXL r3.0 Table 8-42: (30h + 50h)
> > + * For lack of UUID: - 10h
> > + *
> > + * (30h + 50h) - 10h = 70h
> > + */
> > +#define CPER_CXL_COMP_EVENT_LOG_SIZE 0x70
> > +#define CPER_CXL_DEVICE_ID_VALID		BIT(0)
> > +#define CPER_CXL_DEVICE_SN_VALID		BIT(1)
> > +#define CPER_CXL_COMP_EVENT_LOG_VALID		BIT(2)
> > +struct cper_cxl_event_rec {
> > +	struct {
> > +		u32 length;
> > +		u64 validation_bits;
> > +		struct {
> > +			u16 vendor_id;
> > +			u16 device_id;
> > +			u8 func_num;
> > +			u8 device_num;
> > +			u8 bus_num;
> > +			u16 segment_num;
> > +			u16 slot_num; /* bits 2:0 reserved */
> > +			u8 reserved;
> > +		} device_id;
> > +		struct {
> > +			u32 lower_dw;
> > +			u32 upper_dw;
> > +		} dev_serial_num;
> > +	} hdr;
> > +
> > +	u8 comp_event_log[CPER_CXL_COMP_EVENT_LOG_SIZE];
> 
> Rather than define CPER_CXL_COMP_EVENT_LOG_SIZE I would prefer that CXL
> and EFI share a common struct definition for these common fields.
> 
> That would also remove the need for BUILD_BUG_ON() since they literally
> can not disagree on the size in that case.

I don't know if we discussed this publicly or internally but I had
versions which lifted the CXL structs to the core.  But your opinion at
that time was it was not needed.

Looking at it again I might get away with the main event record struct
defined here.  But it is kind of odd to be in efi.h IMO.

> 
> > +};
> > +#define CPER_CXL_REC_LEN(rec) (rec->hdr.length - sizeof(rec->hdr))
> > +
> > +enum cxl_cper_event {
> > +	CXL_CPER_EVENT_GEN_MEDIA,
> > +	CXL_CPER_EVENT_DRAM,
> > +	CXL_CPER_EVENT_MEM_MODULE,
> > +};
> 
> It follows from defining that common data structure above that this enum
> would be a generic CXL namespace that drops "_CPER_". I.e. the CPER
> notification handler and the native driver translate the event to this
> common generic sub-structure that gets emitted.

Ok this would be along the lines of promoting the definitions to a common
header.  Again I kept things pretty separate because it seemed that was
the direction you wanted to go.

I don't particularly like the memcpy which Smita flagged either.  But I
think this will require reworking the trace code to take a 'non-uuid'
structure equal to the payload 'comp_event_log' above.

Based on these comments I'll add some header promotion of common record
structures and see how it works out with the modified trace code.

Do you have any opinions on the name of the core header?

Ira