[Bug 207177] New: KVM nested VMM direct MTF event injection fails

[bugzilla-daemon@bugzilla.kernel.org]

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@kernel-bugs.osdl.org
          Reporter: dpreed@deepplum.com
        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.