Appears this also can be reproduced with 5.4 kernel too.
And from windows debugger dump, arg3 the LVTT 0x320 seems corrupted
and the patchguard complaining. But also from the dump full lapic 4k page is 0, not just 0x320 offset.
Thanks,
Suresh
On 5/12/20, 9:21 PM, "kvm-owner@xxxxxxxxxxxxxxx on behalf of Suresh Gumpula" <kvm-owner@xxxxxxxxxxxxxxx on behalf of suresh.gumpula@xxxxxxxxxxx> wrote:
Hi,
We are a seeing a problem with windows guests(2016/2012R2) where guest crashes with
Virtual APIC page corruption similar to the following redhat ticket.
https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1751017&d=DwIGaQ&c=s883GpUCOChKOHiocYtGcg&r=nwda3lAP7hp57HFC_RJglj6ciwz98d-U4grSzoi79ms&m=JmF-BAGwMBgFp2S9HWvbSsqMj8rJSO_dyYSzImngOYc&s=m9NzlXWIWtaKstvIZLZDESPhfve_xGYWjSF_AWf9CQQ&e=
> Arg4: 0000000000000017, Type of corrupted region, can be
16 : Critical floating point control register modification
17 : Local APIC modification
Here, we are seeing the corruption LAPIC page and guest is BSOD'ing.
Looking at the guest windows dump, we see the full page is zeroed. And it seems the
Guest windows kernel patchguard is detecting this case and resetting the VM.
Is it possible that KVM, somehow corrupted the virtual LAPIC page? While the guest is running
the KVM is not supposed to touch that vcpu lapic page?
Could you please give us some pointers on what could wrong here. Is it a known issue in the kvm?
We are using the host kernel 4.19 and qemu 2.12 and windows guests(2016/2012)
Thanks,
Suresh
