All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bug 207177] New: KVM nested VMM direct MTF event injection fails
@ 2020-04-09 18:33 bugzilla-daemon
  2020-06-10 18:54 ` [Bug 207177] " bugzilla-daemon
  0 siblings, 1 reply; 2+ messages in thread
From: bugzilla-daemon @ 2020-04-09 18:33 UTC (permalink / raw)
  To: kvm

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug 207177] KVM nested VMM direct MTF event injection fails
  2020-04-09 18:33 [Bug 207177] New: KVM nested VMM direct MTF event injection fails bugzilla-daemon
@ 2020-06-10 18:54 ` bugzilla-daemon
  0 siblings, 0 replies; 2+ messages in thread
From: bugzilla-daemon @ 2020-06-10 18:54 UTC (permalink / raw)
  To: kvm

https://bugzilla.kernel.org/show_bug.cgi?id=207177

--- Comment #1 from David P. Reed (dpreed@deepplum.com) ---
Note: it appears that a fix was merged into the kernel via commit b045ae906b4,
by Oliver Updon. Thanks!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-06-10 18:54 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-09 18:33 [Bug 207177] New: KVM nested VMM direct MTF event injection fails bugzilla-daemon
2020-06-10 18:54 ` [Bug 207177] " bugzilla-daemon

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.