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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/03/14 15:10, Jan Beulich wrote:
>>>> 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.

This is just one of the many things in the mess which is the current
cpuid policy/levelling code where libxc and disagree in an unsafe way.

In this particular case, it is not valid for libxc to be able to set any
policy which would make cpuid.0x80000008.eax able to report a physical
width greater than currently supported on the cpu, or less than is
architecturally supported for long mode (which I believe is indeed 36
bits, but cant offhand remember where I read this).

My proposal for this was for there to be very strict sanity checking
when trying to upload the policy leaves, which removes large quantities
of Xen's second-guessing in locations such as this.

~Andrew

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