https://bugzilla.kernel.org/show_bug.cgi?id=207177 Bug ID: 207177 Summary: KVM nested VMM direct MTF event injection fails Product: Virtualization Version: unspecified Kernel Version: 5.5.11 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: kvm Assignee: virtualization_kvm@xxxxxxxxxxxxxxxxxxxx Reporter: dpreed@xxxxxxxxxxxx Regression: No I'm writing a specialized VMM and debugging it under KVM (that is, a KVM guest). Both L0 host and its guest are running Fedora 31 kernel 5.5.11-200, FYI. The VMM creates a VMCS and vmlaunch's it. If bit 27 of primary processor controls is set, the first VMEXIT is indeed Exit Reason 37 (monitor trap fault), as would be expected. No problem here. However, in the Intel SDM volume 3C, Chapter 26.6.2, there is another documented way to *inject* a "one-time" MTF exit. To wit, "If the interruption type in the VM-entry interruption-information field is 7 (other event) and the vector field is 0, VM entry cases an MTF VM exit to be pending on the instruction boundary following VM entry. See section 25.5.2 for the treatment of pending MTF exits." So repeat the experiment, but with the VMCS having bit 27 of the primary processor controls clear, but with the entry interruption information field set to 0x80000700, per the manual. No VMEXIT happens, though other VMEXITS subsequent do happen. In other words, the "injection method" fails. I have tried the same identical binary on the same system as the guest Fedora 31, running on bare metal on the same hardware. The behavior is precisely as documented in the Intel SDM section above. So clearly the nested KVM mechanics do not properly handle the injection of an MTF via the VM-entry interruption information field. This is a useful feature, so I hope the bug will be fixed, allowing me to debug my code under KVM. Thanks. -- You are receiving this mail because: You are watching the assignee of the bug.
