Re: [PATCH 22/24] Correct handling of idt vectoring info

["Nadav Har'El" <nyh@math.technion.ac.il>]

On Thu, Jun 17, 2010, Gleb Natapov wrote about "Re: [PATCH 22/24] Correct handling of idt vectoring info":
> On Sun, Jun 13, 2010 at 03:33:50PM +0300, Nadav Har'El wrote:
> > In the normal non-nested case, the idt_vectoring_info case is treated after
> > the exit. However, in the nested case a decision of whether to return to L2
> This is not correct. On the normal non-nested case the idt_vectoring_info is
> parsed into vmx/svm independent data structure (which is saved/restored during
> VM migartion) after exit. The reinjection happens on vmentry path.

You're right that perhaps I overstated the difference between the nested
and normal case. In both cases, the code at the end of vmx_vcpu_run just
remembers what to do, and the actual injection (namely, setting the vmcs)
happens in the beginning of the next entry. I'll change the wording of the
patch's description to make it more accurate.

> Why can't you do that using existing exception/nmi/interrupt queues that
> we have, but instead you effectively disable vmx_complete_interrupts()
> by patch 18 when in nested mode and add logically same code in this
> patch. I.e after exit you save info about idt event into nested_vmx
> and reinject it on vm entry.

This is an interesting point.

The basic problem is that (as I explained in the patch's description) when
L2 exits to L1 with idt vectoring info, L0 should *not* do its normal
thing of injecting the event - it should basically do nothing, and just
leave the IDT_VECTORING_INFO_FIELD in vmcs12 for L1 to find and act upon.
So in this case we must eliminate the normal decision that KVM would make
to inject the event.

Perhaps it would have been possible to leave the decision as-is (i.e.,
not change vmx_complete_interrupts()), but instead disable the injection
itself in inject_pending_event() (in x86.c, not vmx.c) or in all of
vmx_queue_exception, vmx_set_nmi and vmx_set_irq. But I'm not sure this will
be a cleaner patch (and I'd especially like to avoid nested-specific changes
in x86.c), and I'm pretty sure that however I change this code, it's bound
to break in subtle ways. The current patch took some blood, toil, tears
and sweat (well, maybe everything except the blood...) of my coworkers 
to get right :-)

Nadav.

-- 
Nadav Har'El                        |      Sunday, Sep 19 2010, 12 Tishri 5771
nyh@math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Life is what happens to you while you're
http://nadav.harel.org.il           |busy making other plans. - John Lennon