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, "[email protected] on behalf of Suresh Gumpula" <[email protected] on behalf of [email protected]> 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
