From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: [PATCH] SVM: do not generate "external interrupt exit" if other exit is pending Date: Sun, 19 Sep 2010 20:19:33 +0200 Message-ID: <20100919181933.GG15338@8bytes.org> References: <20100919164127.GC3008@redhat.com> <20100919172941.GF15338@8bytes.org> <20100919175027.GA12883@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, avi@redhat.com, mtosatti@redhat.com, joerg.roedel@amd.com, agraf@suse.de To: Gleb Natapov Return-path: Received: from 8bytes.org ([88.198.83.132]:53760 "EHLO 8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754806Ab0ISSTf (ORCPT ); Sun, 19 Sep 2010 14:19:35 -0400 Content-Disposition: inline In-Reply-To: <20100919175027.GA12883@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Sep 19, 2010 at 07:50:27PM +0200, Gleb Natapov wrote: > On Sun, Sep 19, 2010 at 07:29:41PM +0200, Joerg Roedel wrote: > > On Sun, Sep 19, 2010 at 06:41:27PM +0200, Gleb Natapov wrote: > > > Nested SVM checks for external interrupt after injecting nested exception. > > > In case there is external interrupt pending the code generates "external > > > interrupt exit" and overwrites previous exit info. If previously injected > > > exception already generated exit it will be lost. > > > > Right. Have you seen specific mismehavior due to this problem? I am just > > curious how you found this :-) > Yes. Trying to make async page fault work with nested svm :) It was hard > to fix with reproducible test case. I am not dreaming to fix it just by > code review. Interesting. Hope this was the only problem and you have it working now? > > And another question, can you put the reason for this "if(...) return" > > into an comment before the statement? The whole svm-emulation thing is > > complicated enough so that we should document it well in the code :-) > > > Complicated is understatement. Will add a comment. Thanks, the most complicated thing is to get all the interrupt- exception- and event-reinjection thing right. You just fixed another bug there, thanks again :) Joerg