Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Date:   Tue, 31 Oct 2023 20:35:49 -0700
From:   Ira Weiny <ira.weiny@intel.com>
To:     Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
        Ira Weiny <ira.weiny@intel.com>,
        Dan Williams <dan.j.williams@intel.com>,
        "Jonathan Cameron" <jonathan.cameron@huawei.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>
Subject: Re: [PATCH RFC v2 3/3] cxl/memdev: Register for and process CPER
 events
Message-ID: <6541c795e39b_2e75b294e0@iweiny-mobl.notmuch>
References: <20230601-cxl-cper-v2-0-314d9c36ab02@intel.com>
 <20230601-cxl-cper-v2-3-314d9c36ab02@intel.com>
 <81b90308-fdb1-3686-33a3-1e7ec42a7ef8@amd.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <81b90308-fdb1-3686-33a3-1e7ec42a7ef8@amd.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?r3aw+HhWzUGTlsE3XGr68DIFWHYsnjOgXUW6PkvGgZuinYWjNoXwUwIFhHms?=
 =?us-ascii?Q?aoYGEX+7geYNo9D5+z38LwCtJHIED3JX2Wt7vsUsOlkpPxMP9qv0k7gJM4kP?=
 =?us-ascii?Q?wYbQXbPPtfA/v0e43i+ANcW5ZWdAL+H1FXvw9qtoI5Wvmxr42b1A+hCu3tZN?=
 =?us-ascii?Q?JXRlbEtTRKePIayUGZPK6W3Tcu0nP0S5YBMmcnCosJ1nJV3VUNYnmo8Yxl5h?=
 =?us-ascii?Q?P42BHtRtR/p5TvEFl8nTvWIpp7DGtlAm1oMmj6s/KxnNdQHHLaM96FXUlYim?=
 =?us-ascii?Q?gCL30oAu/CzOd+3YeemNcbaldbA8UjXzYYfNz+GlZ39Cou4br1nrNgpwWTlc?=
 =?us-ascii?Q?HO43jxwnFJZKfc0OyGmsojAbHAjSdv4AqxfscV1VZiu29whajnNw0D3/h55Z?=
 =?us-ascii?Q?a9x/v0dflqumSZviuKg+GambWTJdLr7fYY/tfgdV33+F7VX+y2+xYplQmKr/?=
 =?us-ascii?Q?LETQqWDGAeXYRWFj8gpp6pTbE3FXPx1VWxm3gJNtTbscTp+A7abuXbuBU3p1?=
 =?us-ascii?Q?+29pEjI/zjJSDIEpJMOcWRbgPdxZnmujJOx4KVz0Opilw4IlNEoHXQn9coWf?=
 =?us-ascii?Q?/mWHq54MfBYpA62t4qaixjI/4P9s17wGfMMK3HVGV7SREjBR9f67rWjoPIbH?=
 =?us-ascii?Q?Fna+amemEDbng0zeiO2fwhEMftl9Q1FOmSkTWFa2T9yz85QzbzK7eqCQJl8F?=
 =?us-ascii?Q?yp2wWsU8ht/81oK+7EhTI1VqvwVbJJymxH7mB81mvZkSfl/v+vPWp7vKrizJ?=
 =?us-ascii?Q?O1L3xqmyc1+GL5Yz5HLEoCEwe7QF0qR0GlSfpGuQ+NxfcP9j5UpWPvDwhq51?=
 =?us-ascii?Q?sK5qs0DI1C04bzc070ZMh4DUQ6J/zWoCdRpq+RM7zlyB/bpXC2l48q3YYsf0?=
 =?us-ascii?Q?BhocNp+Mk13sHeUYGWlOmLsgNwlDAd/H4Ql+durJBr4gTc0VN/Hq3MGmgJW/?=
 =?us-ascii?Q?1Tu9RFHXOygRA9T8vFc4kmPbadzhngMyAfWigUh2S1qLDCjJRT1dkRjitFLQ?=
 =?us-ascii?Q?cV6RkMQUPGGCR5P6WmMFR+RpVFB1tOuxhNtj4u0AQxStpz6OwGuPQ6SlNfKL?=
 =?us-ascii?Q?u02RVGIGfLvMpjG488k+Yz3SMFviGtFEVLPSDI6J/qjRxoLyTa6Tm2e4J5Ua?=
 =?us-ascii?Q?T4hlqUljJcvIW9fhGFX00F7LPn9rCg9aJ7x3R4H2NYiEtUwrqY0sp5bAHbsP?=
 =?us-ascii?Q?WzsDAE2jfasYgNIEOPc4/ydrHK0Vl0a+lDec+Opyi0I63JIU36Vj8ZRmTmTG?=
 =?us-ascii?Q?5oT2or95lSvLdHnzqAmqoxUwQ48VyybXFtDh9geu1pRM/USnEL+9Q1/OXdiI?=
 =?us-ascii?Q?scznfFNF7UxKmKkNjisHIgpLOgt+NKa+2o0A8M5s1eahoE9ohL0eRNsVfJ5O?=
 =?us-ascii?Q?gjGOAupZEAHQrkBb06eL9TBrNgMmhvFGkFsDnvicW7QDueDZvSyta3RBg2q5?=
 =?us-ascii?Q?+I7LnZolw1W0lPmFsgovZHE4FieHBW58gXg3ejerGTTEG1Dm4bFQ2BHRF+5U?=
 =?us-ascii?Q?Wp7dA8UVj00OwyfGwxDN/i/k58YCyV72ksHb9ToDnEM7PQ1KpmDCehYMkNj0?=
 =?us-ascii?Q?/TE22JMK1h7z05YSBiKXMDsGyowV5XIv5C39evg4?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 6e8b536a-55c5-48db-f9c7-08dbda8ba63c
X-MS-Exchange-CrossTenant-AuthSource: SA1PR11MB6733.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2023 03:35:52.9175
 (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: /AP1GCjc7uJqmcIc5snltuC0RgdMTED8sXdFy/+smbQFwo8fi2hXDMfpiM2slEMS0lN5nMCLStpH98GJpevs7A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR11MB7937
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,
	URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.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 (lipwig.vger.email [0.0.0.0]); Tue, 31 Oct 2023 20:36:27 -0700 (PDT)

Smita Koralahalli wrote:
> >   

[snip]

> > +#define CXL_EVENT_HDR_FLAGS_REC_SEVERITY GENMASK(1, 0)
> > +int cxl_cper_event_call(struct notifier_block *nb, unsigned long action, void *data)
> > +{
> > +	struct cxl_cper_notifier_data *nd = data;
> > +	struct cxl_event_record_raw record = (struct cxl_event_record_raw) {
> > +		.hdr.id = UUID_INIT(0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0),
> > +	};
> > +	enum cxl_event_log_type log_type;
> > +	struct cxl_memdev_state *mds;
> > +	u32 hdr_flags;
> > +
> > +	mds = container_of(nb, struct cxl_memdev_state, cxl_cper_nb);
> > +
> > +	/* Need serial number for device identification */
> > +	if (!(nd->rec->hdr.validation_bits & CPER_CXL_DEVICE_SN_VALID))
> > +		return NOTIFY_DONE;
> 
> For all the event records that I tested so far, this has never been 
> true. That is CPER_CXL_DEVICE_SN_VALID is never set which might not log 
> the records at all. Should we be bit more lenient here and include 
> validating device_id (bdf) instead and check if cxlds exist?
> 
> pci_get_domain_bus_and_slot() and pci_get_drvdata()..

Checking BDF is reasonable.  Not sure what you mean by 'check if cxlds
exists'?

This will be called on each memdev so the cxlds should be valid.  Do you
think we need some locking?  I think the unregister will block device
removal if this is running.

> 
> > +
> > +	/* FIXME endianess and bytes of serial number need verification */
> > +	/* FIXME Should other values be checked? */
> > +	if (memcmp(&mds->cxlds.serial, &nd->rec->hdr.dev_serial_num,
> > +		   sizeof(mds->cxlds.serial)))
> > +		return NOTIFY_DONE;
> > +
> > +	/* ensure record can always handle the full CPER provided data */
> > +	BUILD_BUG_ON(sizeof(record) <
> > +		(CPER_CXL_COMP_EVENT_LOG_SIZE + sizeof(record.hdr.id)));
> > +
> > +	/*
> > +	 * UEFI v2.10 defines N.2.14 defines the CXL CPER record as not
> > +	 * including the uuid field.
> > +	 */
> > +	memcpy(&record.hdr.length, &nd->rec->comp_event_log,
> > +		CPER_CXL_REC_LEN(nd->rec));
> 
> I'm doubtful this will do the job.

I'm not sure why but, see below...

> I think we should copy into each 
> field of struct cxl_event_record_hdr individually starting from length 
> by pointer arithmetic (which is definitely bad, but I cannot think of a 
> better way to do this) and then do memcpy for data field in struct 
> cxl_event_record_raw..
> 
> Any other suggestions would be helpful as well.

Based on Dan's suggestion to share the structures this memcpy can be
avoided altogether.  Let's see how that works.

> 
> I can make these changes and validate it on my end if that works..?

Any testing would be welcome.  I don't have a test setup readily
available.

Ira

[snip]