Interrupt-window exiting

Interrupt-window exiting

Tracy Camp's picture
Tracy Camp
Thu, 07/28/2011 - 20:44

I'm attempting to implement a scheme where interrupts cause exits to vmxroot and then I inject them back into a guest domain. However I believe it would only be appropriate to inject an interrupt to the guest if RFLAGS.IF = 1. As such I've implemented a local APIC state machine. However to deliver pending interrupts to the guest I need an exit when RFLAGS.IF transitions from 0 to 1. From the documentation I've been led to believe that the 'Interrupt-window exiting' primary proc vm control bit would provide this exit. However, I don't seem to be getting exit conditions when I set this in my VMCS and resume the guest.

Do I mis-understand the purpose of this exit condition? Am I barking up the wrong tree with detecting RFLAGS.IF transitions? Thanks!

RSS Top
6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Tracy Camp's picture
Tracy Camp
Sun, 07/31/2011 - 10:23

To follow up on my own question... I found that I was not actually setting the proc control bit in the effective VMCS structure, so that is why I wasn't seeing the exits. However I would still appreciate some confirmation that I correctly understand the purpose of this proc control.

Top
David Ott (Intel)'s picture
David Ott (Intel)
Mon, 08/15/2011 - 16:20

Yourunderstanding about interrupt-window exiting is correct, but the exit would only happen when its eligible to deliver an interrupt in the guest context. RFLAGS.IF is one condition, but there may be other conditions which block interrupts, thus preventingan exit. You should take a look at section 21.4.2 Guest Non-Register State and related knowledge in the Intel 64 and IA-32 Architectures Developer's Manual: Vol. 3B at

http://www.intel.com/products/processor/manuals/

Another point is thatyou need to check what the current guest context is. Since youare implementing yourown APIC model, one of the first things tocheck is whether the guest is actually progressing in the early boot stage. If the guest already blocks or crashesin theAPIC initialization phase, its possible that interrupt-window exiting has no way to take effect.

David Ott

Top
Tracy Camp's picture
Tracy Camp
Tue, 08/16/2011 - 20:39

Thank you very much for your helpful reply.

On a related topic, the 'acknowledge interrupt on exit' exit control (3b 27.7.1) does not imply that an EOI is issued to the local APIC (presuming it is enabled) when an external interrupt exit occurs? It is still necissary for the vmm or guest if the interrupt is injected to a guest context that has 'ownership' of the local APIC to issue an EOI to clear the ISR?

It seems logical that that the EOI would need to be explititly sent by the programmer, but if that is true, I'm having a hard time understanding what purpose this exit control exists for? The documentation appears to state that an external interrupt exit would occur, but the exit information would be invalid if the control set not set. I'm just not sure why one would ever want that particular behavior, so I'm wondering again if I understand this exit control correctly.

Thank you again,

t.

Top
Tracy Camp's picture
Tracy Camp
Sun, 08/21/2011 - 12:59

To self follow-up again, I did some experiments and it appears that the 'acknowledge interrupt on exit' does in fact issue the EOI to the local APIC upon external interrupt exit, which I suppose suggests a function for this exit control. If the control is not set, the vmm can still arrange for an exit to occur when an interrupt is delivered, but not need to handle it in any manner other than possibly switch the current VMCS to some other guest context that 'owns' the local APIC hardware.

Do I have this anywhere correct? Sorry, the documentation is precise, but does not exactly provide explainitory background detail and ends up being something of a 'choose your own adventure' story....

Top
David Ott (Intel)'s picture
David Ott (Intel)
Mon, 08/29/2011 - 13:46

Commentsbelow.

On a related topic, the 'acknowledge interrupt on exit' exit control (3b 27.7.1) does not imply that an EOI is issued to the local APIC (presuming it is enabled) when an external interrupt exit occurs?

Correct.

It is still necissary for the vmm or guest if the interrupt is injected to a guest context that has 'ownership' of the local APIC to issue an EOI to clear the ISR?

If the guest has ownership of the local APIC, itcan do EOI as normal at the end of the interrupt service routine. Keep in mind, until the EOI happens (which is when the ISR gets cleared in the local APIC), other lower priority interrupts (even if they are destined to VMM) will be blocked by the local APIC.

It seems logical that that the EOI would need to be explititly sent by the programmer, but if that is true, I'm having a hard time understanding what purpose this exit control exists for? The documentation appears to state that an external interrupt exit would occur, but the exit information would be invalid if the control set not set. I'm just not sure why one would ever want that particular behavior, so I'm wondering again if I understand this exit control correctly.

I assume that this exit control means 'acknowledge interrupt on exit'.If software doesnt enable 'acknowledge interrupt on exit'when an external interrupt comes, you would not get the interrupt vector as part of the VM exit. (The CPU would not acknowledge the interrupt and get it from the Local APIC, which means the interrupt is still held in the IRR of local APIC.) Instead, after a VM-exit, software would have to explicitly unblock interrupts to take the interrupt as normal through the IDT. This control has nothing to do with EOI.

David Ott

Top

Login to leave a comment.