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. 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 :-( > 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? 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. -- Nadav Har'El | Monday, Sep 20 2010, 12 Tishri 5771 nyh@xxxxxxxxxxxxxxxxxxx |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |Bore, n.: A person who talks when you http://nadav.harel.org.il |wish him to listen. -- 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
