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.