From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 22/24] Correct handling of idt vectoring info Date: Mon, 20 Sep 2010 12:11:28 +0200 Message-ID: <4C973350.7070203@redhat.com> References: <1276431753-nyh@il.ibm.com> <201006131233.o5DCXoel013156@rice.haifa.ibm.com> <20100617115803.GP523@redhat.com> <20100920063704.GA29641@fermat.math.technion.ac.il> <20100920093440.GH3008@redhat.com> <20100920100340.GB29641@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , kvm@vger.kernel.org To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:19156 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753816Ab0ITKLe (ORCPT ); Mon, 20 Sep 2010 06:11:34 -0400 In-Reply-To: <20100920100340.GB29641@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: 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