Re: [PATCH v2 1/3] x86: Add AMD's CpuidUserDis bit definitions

[Jan Beulich <jbeulich@suse.com>]

On 11.05.2023 12:38, Alejandro Vallejo wrote:
> On Thu, May 11, 2023 at 11:41:13AM +0200, Jan Beulich wrote:
>> On 09.05.2023 18:43, Alejandro Vallejo wrote:
>>> --- a/xen/include/public/arch-x86/cpufeatureset.h
>>> +++ b/xen/include/public/arch-x86/cpufeatureset.h
>>> @@ -287,6 +287,7 @@ XEN_CPUFEATURE(AVX_IFMA,     10*32+23) /*A  AVX-IFMA Instructions */
>>>  /* AMD-defined CPU features, CPUID level 0x80000021.eax, word 11 */
>>>  XEN_CPUFEATURE(LFENCE_DISPATCH,    11*32+ 2) /*A  LFENCE always serializing */
>>>  XEN_CPUFEATURE(NSCB,               11*32+ 6) /*A  Null Selector Clears Base (and limit too) */
>>> +XEN_CPUFEATURE(CPUID_USER_DIS,     11*32+17) /*   CPUID disable for non-privileged software */
>>
>> While I can accept your argument towards staying close to AMD's doc
>> with the name, I'd really like to ask that the comment then be
>> disambiguated: "non-privileged" is more likely mean CPL=3 than all
>> of CPL>0. Since "not fully privileged" is getting a little long,
>> maybe indeed say "CPL > 0 software"? [...]
> 
> Fair point. That was copied from AMD's PM, but there's no good reason to
> keep it that way. I'll modify it as you pointed out.
> 
>> I would then offer you my R-b,
>> if only I could find proof of the HWCR bit being bit 35. The PM
>> mentions it only by name, and the PPRs I've checked all have it
>> marked reserved.
> 
> It is in the Vol2 of the PM. Section 3.2.10 on the HWCR. I'm looking at
> revision 4.06, from January 2023.

Oh, my fault then: It didn't even occur to me to check Vol 2, as normally
it's the other way around: Only the PPRs can be sufficiently relied upon
to be at least halfway complete.

With the comment adjustment (which I'd also be okay to do while committing)
then
Reviewed-by: Jan Beulich <jbeulich@suse.com>

Jan