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