Bug 207177 - KVM nested VMM direct MTF event injection fails
Summary: KVM nested VMM direct MTF event injection fails
Status: NEW
Alias: None
Product: Virtualization
Classification: Unclassified
Component: kvm (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: virtualization_kvm
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-09 18:33 UTC by David P. Reed
Modified: 2020-06-10 18:54 UTC (History)
1 user (show)

See Also:
Kernel Version: 5.5.11
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description David P. Reed 2020-04-09 18:33:45 UTC
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.
Comment 1 David P. Reed 2020-06-10 18:54:30 UTC
Note: it appears that a fix was merged into the kernel via commit b045ae906b4, by Oliver Updon. Thanks!

Note You need to log in before you can comment on or make changes to this bug.