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@xxxxxxxxxxxxxxxxxxxx ReportedBy: nyh@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
