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

[Gleb Natapov <gleb@redhat.com>]

On Sun, Sep 26, 2010 at 05:14:37PM +0200, Avi Kivity wrote:
>  On 09/23/2010 01:15 AM, Nadav Har'El wrote:
> >On Mon, Sep 20, 2010, Avi Kivity wrote about "Re: [PATCH 22/24] Correct handling of idt vectoring info":
> >>  >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.
> >
> >Thanks. I guess I need to do some serious reading on this subject. I guessed
> >that exit_int_info was more of a parallel of VMX's vm_exit_intr_info field and
> >not idt_vectoring_info, but I guess I was wrong.
> 
> svm has separate intercepts for every exception, so it doesn't need
> the vector field of vm_exit_intr_info_field.  The error code is
> stored in exit_info_1, cr2 (for #PF) in exit_info_2.
> 
> >>  >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.
> >
> >Can you please clarify? I didn't understand what "it" refers to here.
> >
> >
> 
> Sorry, it was a week ago.
> 
> In general I think both svm and vmx need to go through the
> exception/interrupt queues.  That is, if you exit with
> IDT_VECTORING_INFO_VALID, you unpack it into the queue as a pending
> exception, and when you enter again you load it into
> VM_ENTRY_INTR_INFO_FIELD.  That's a bit of work, but it reduces the
> amount of code paths when L0 needs to inject an exception into L2
> (like in emulation) - all it has to do is to queue it into the
> generic exception queue.
> 
And if L0 needs to reinject event directly into L2 it just uses regular
L0 code path instead of ah-hoc nested_handle_valid_idt_vectoring_info()
function.

--
			Gleb.