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.jasudow...@cert.pl>

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

Reply via email to