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

[Tim Deegan <tim@xxxxxxx>]

At 15:10 +0000 on 27 Mar (1395929407), Jan Beulich wrote:
> >> @@ -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.

Oh right.  Yes, in that case these seem fine.   And until Andrew's
series to do such checking at upload time, doing it here is consistnet
with how other leaves are handled. 

My comment about advertising 64-bit linear addresses is also clearly
incorrect - I was misreading 0x30 as 64 for some reason.

So, Reviewed-by: Tim Deegan <tim@xxxxxxx>

Cheers,

Tim.

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