Re: [Xen-devel] [PATCH] x86/HVM: correct CPUID leaf 80000008 handling

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.03.14 at 12:44, <tim@xxxxxxx> wrote:
> At 11:48 +0000 on 26 Mar (1395830898), Jan Beulich wrote:
>> CPUID[80000001].EAX[23:16] have been given the meaning of the guest
> 
> s/80000001/80000008/?

Oops, of course.

>> @@ -3083,6 +3083,23 @@ void hvm_cpuid(unsigned int input, unsig
>>          if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
>>              *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);
>>          break;
>> +
>> +    case 0x80000008:
>> +        count = cpuid_eax(0x80000008);
>> +        count = (count >> 16) & 0xff ?: count & 0xff;
>> +        if ( (*eax & 0xff) > count )
>> +            *eax = (*eax & ~0xff) | count;
>> +
>> +        hvm_cpuid(1, NULL, NULL, NULL, &_edx);
>> +        count = _edx & (cpufeat_mask(X86_FEATURE_PAE) |
>> +                        cpufeat_mask(X86_FEATURE_PSE36)) ? 36 : 32;
>> +        if ( (*eax & 0xff) < count )
>> +            *eax = (*eax & ~0xff) | count;
> 
> What is this for?  Surely if the CPU really claims to have a paddr
> limit lower than 32 then (a) it's buggy and (b) we can't just pretend
> it doesn't say that.

But what we modify isn't what came from hardware, but what was
presented (possibly overridden) by the tool stack.

>  And architecturally, the presence of PSE/PAE
> doesn't guarantee that the CPU will support a given paddr width.
> (My reading of the AMD docs says you get up-to-40/up-to-52 but gives
> no lower bound).

Clearly the lower bounds are implied, and PSE/PAE in fact do
guarantee 36 bits to be supported (and 32 bits have always been
afaict, at least since the introduction of CPUID).

In any event - what alternatives would you suggest?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel