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

[Avi Kivity <avi@redhat.com>]

  On 09/20/2010 12:03 PM, Nadav Har'El wrote:
> On Mon, Sep 20, 2010, Gleb Natapov wrote about "Re: [PATCH 22/24] Correct handling of idt vectoring info":
> >  But your code disables normal path even if L0 is the one who should
> >  handle exit and re-inject event into L2. Look at what nested SVM is doing.
> >  It is checking in handle_exit() if vmexit should cause vmexit into L1
> >  and if so they bypass regular code path by emulating exit instead, but if
> >  L0 should handle the vmexit it uses regular code path.
>
> I wish it could be this simple. In vmx.c, we unfortunately don't have one
> such decision point (of when to exit into L1), but two: one is the exit
> handling (like in svm), but there's another one in the injection path
> (vmx_queue_exception): namely, when KVM decides to injects a #PF (because
> the guest, not it, should have gotten this #PF), we also need to exit to L1,
> and we only discover this in the entry path, not the exit path.

This is not specific to #PF, we queue other exceptions as well, for 
example #GP and #UD.  They all need to be checked against EXCEPTION_BITMAP.

> We could have changed the code to do this special PF handling not in the
> entrance but rather at the point at the exit when this event is being queued.
> We probably should. But I'm afraid that this would require quite a bit of
> changes in the non-nested vmx (and possibly x86) code, which we wanted to
> avoid making. I'm also afraid that I don't understand all the reasons that
> brought to the current situation :-(

Maybe add a queue (like the exception queue) to hold those pending exits?

Then kvm_queue_exception() could check of an intercept and queue a 
vmexit instead.

> >  Look at how SVM did it. VMX shouldn't be different.
>
> I'm afraid I know very little about the SVM architecture. Does SVM even have
> a parallel of the IDT_VECTORING_INFO that this patch is trying to address?

It does. exit_int_info.

> I agree that the nested SVM's handle_exit() looks cleaner that the parallel
> code in nested VMX. The root of all evil is that second exit decision point
> in the injection phase, and I'll think some more if I can find a way to
> avoid it without rocking the foundations too much.
>

I think svm needs it too.

-- 
error compiling committee.c: too many arguments to function