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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
