Re: [PATCH] x86/cpuid: Expose number of vCPUs in CPUID.1.EBX

[Hubert Jasudowicz <hubert.jasudowicz@xxxxxxx>]

On 6/18/20 6:51 PM, Andrew Cooper wrote:
> On 18/06/2020 17:22, Hubert Jasudowicz wrote:
>> When running under KVM (or presumably other hypervisors) we enable
>> the CPUID.1.EDX.HTT flag, thus indicating validity of CPUID.1.EBX[23:16]
>> - maximum number of logical processors which the guest reads as 0.
>>
>> Although this method of topology detection is considered legacy,
>> Windows falls back to it when CPUID.0BH.EBX is 0.
>>
>> CPUID.1.EBX[23:16] being equal to 0, triggers memory corruption in
>> ntoskrnl.exe as Windows assumes that number of logical processors would
>> be at least 1. Memory corruption manifests itself while mapping
>> framebuffer for early graphical subsystem, causing BSOD.
>>
>> This patch fixes running nested Windows (tested on 7 and 10) with KVM as
>> L0 hypervisor, by setting the value to maximum number of vCPUs in domain.
>>
>> Signed-off-by: Hubert Jasudowicz <hubert.jasudowicz@xxxxxxx>
> 
> I'm afraid fixing guest topology is more complicated than just this.  On
> its own, I'm not sure if this is safe for VMs migrating in.
> 
> While I agree that Xen's logic is definitely broken, I suspect the
> conditions for the BSOD are more complicated than this, because Windows
> does work fine when there is no KVM in the setup described.
> 
> ~Andrew
> 

After some more testing, I've managed to boot Windows by explicitly configuring 
the guest
with cpuid="host,htt=0". If I understand correctly, the default behavior is to
enable HTT for the guest and basically pass through the value of 
CPUID.1.EBX[23:16]
without any sanity checks.

The reason this works in other setups is that the non-zero value returned by 
real hardware
leaks into the guest. In my setup, what Xen sees is:
CPUID.1h == EAX: 000806ea EBX: 00000800 ECX: fffab223 EDX: 0f8bfbff

In terms of VM migration, this seems already broken because guest might read 
different
values depending on what underlying hardware reports. The patch would at least 
provide
some consistency between hosts. Another solution would be not to enable HTT bit 
by default.

Kind regards,
Hubert Jasudowicz