[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB60838E591B5E4EE1DED07869FC402@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Fri, 18 Oct 2024 15:28:42 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Zhuo, Qiuxu" <qiuxu.zhuo@...el.com>, "Naik, Avadhut" <avadnaik@....com>,
"x86@...nel.org" <x86@...nel.org>, "linux-edac@...r.kernel.org"
<linux-edac@...r.kernel.org>, "linux-trace-kernel@...r.kernel.org"
<linux-trace-kernel@...r.kernel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"bp@...en8.de" <bp@...en8.de>, "tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>, "rostedt@...dmis.org"
<rostedt@...dmis.org>, "mchehab@...nel.org" <mchehab@...nel.org>,
"yazen.ghannam@....com" <yazen.ghannam@....com>, "john.allen@....com"
<john.allen@....com>, Avadhut Naik <avadhut.naik@....com>
Subject: RE: [PATCH v6 3/5] x86/mce, EDAC/mce_amd: Add support for new
MCA_SYND{1,2} registers
> So, this is based on the assumption that all vendor data fields are of the u64 type, which may
> NOT be true for other x86 vendors in the future. In case there is some non-u64 vendor data in
> the future, the parser would need to break the u64 tracing data into u8 data and then composite
> the split u8 data into other types like u16 or u32, which seems even inconvenient.
>
> IMHO: Printing the u8 tracing data and leaving the vendor-specific tool to parse the u8 data is a
> more flexible and balanced approach.
>
> Maybe Boris and Tony could provide more comments here.
I agree. It's hard to predict the future, but there seems to be no guarantee that
vendor specific fields will always be "u64" sized. Perhaps the MSR that data
is picked from has only a few bits defined so we elect to save those bits in
some smaller data type.
-Tony
Powered by blists - more mailing lists