[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/HVM: correct CPUID leaf 80000008 handling
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |