[Bug 53711] New: nVMX: potential bug with IDT_VECTORING_INFO if !PIN_BASED_EXT_INTR_MASK

* [Bug 53711] New: nVMX: potential bug with IDT_VECTORING_INFO if !PIN_BASED_EXT_INTR_MASK
@ 2013-02-12  9:56 bugzilla-daemon
  2013-02-12  9:57 ` [Bug 53711] " bugzilla-daemon
  2015-03-17  3:53 ` bugzilla-daemon
  0 siblings, 2 replies; 3+ messages in thread
From: bugzilla-daemon @ 2013-02-12  9:56 UTC (permalink / raw)
  To: kvm

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

           Summary: nVMX: potential bug with IDT_VECTORING_INFO if
                    !PIN_BASED_EXT_INTR_MASK
           Product: Virtualization
           Version: unspecified
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: kvm
        AssignedTo: virtualization_kvm@kernel-bugs.osdl.org
        ReportedBy: nyh@math.technion.ac.il
        Regression: No

This is a potential bug nested VMX - I just thought about it and don't know if
actually happens.

If !PIN_BASED_EXT_INTR_MASK, our code can inject user-space-specified events
directly into L2.

But what if we also have valid IDT_VECTORING_INFO? In this case, when we
reenter L2, and notice L2 also ran previously, and there is valid
IDT_VECTORING_INFO, we replace the injection field with this
IDT_VECTORING_INFO.

I guess we assumed that if we're in L2 we couldn't have meaningful things in
the injection field because L0 doesn't inject to L2. But it can, when
!PIN_BASED_EXT_INTR_MASK... So maybe we don't support this case correctly.

Kevin Tian also independently thought of this bug in his code review:

Date:   Wed, 25 May 2011 18:02:03 +0800
From: "Tian, Kevin" <kevin.tian@intel.com>
Here got one question. How about L2 has interrupt exiting disabled? That way
it's expect to have L0 directly inject virtual interrupt into L2, and thus
simply overwrite interrupt info field here looks incorrect. Though as you said
typical hypervisor doesn't turn interrupt exiting off, but it does be an
architectural correct thing. I think here you should compare current
INTR_INFO_FIELD with saved IDT_VECTOR and choose a higher priority, when L2 has
interrupt exiting disabled.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

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