On Mon, Sep 20, 2010 at 12:03:40PM +0200, 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. > SVM has exactly same problem. What they do is in svm_queue_exception() they check if exception should generate vmexit and if so they set svm->nested.exit_required flag. They skip next vmentry if the flag is set and proceed directly to handle_exit() where they check this flag one again and emulate nested vmexit. Their nested vmexit emulation clears exception/interrupt queue. > 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 :-( > Nested SVM managed to do it without to much hassle. There is reinject logic in svm_queue_exception() that I still do not understand, but the same logic should be applicable to VMX too since SVM and VMX way of doing virtualization is very similar. > > 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? Exactly same. The way events injection work in SVM and VMX are similar. This allow us to maintain most of the logic in common code. > > 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. > -- 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
