From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: Implement generic double fault generation mechanism Date: Fri, 8 May 2009 15:23:58 +0300 Message-ID: <20090508122358.GF25357@redhat.com> References: <9832F13BD22FB94A829F798DA4A8280501A80F02A3@pdsmsx503.ccr.corp.intel.com> <20090503105330.GL9795@redhat.com> <9832F13BD22FB94A829F798DA4A8280501A81A8E83@pdsmsx503.ccr.corp.intel.com> <20090508095336.GD25357@redhat.com> <9832F13BD22FB94A829F798DA4A8280501A81A8EFE@pdsmsx503.ccr.corp.intel.com> <9832F13BD22FB94A829F798DA4A8280501A81A8F02@pdsmsx503.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kvm@vger.kernel.org" , Avi Kivity To: "Dong, Eddie" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:55018 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752603AbZEHMX7 (ORCPT ); Fri, 8 May 2009 08:23:59 -0400 Content-Disposition: inline In-Reply-To: <9832F13BD22FB94A829F798DA4A8280501A81A8F02@pdsmsx503.ccr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, May 08, 2009 at 06:46:14PM +0800, Dong, Eddie wrote: > Dong, Eddie wrote: > > ction will be re-executed. > >>> > >>> Do you want it to be covered for now? For exception, it is easy but > >>> for IRQ, it needs to be pushed back. > >>> > >> Yes I want it to be covered now otherwise any serial exception > >> generates flood of "Exception happens serially" messages. This > >> function does not handle IRQ so no problem there. > > > > But we soon will let this function cove IRQ as well per SDM. > > Why not do that a little bit later? > > > > BTW, this issue exist in original code as well. > > > > Eddie > > Actually this is already addressed in current patch too: Just keep the former exception. If you mean the prink should be removed, I am fine. Keeping the former exception is not the right thing to do. It can't be delivered because delivering it cause another exception and handler that may fix the situation is not called since you drop last exception and keep re-injecting the one that can't be handled. > BTW, this case doesn't happen in reality. > Then why do you write all this code then? :) I can easily write test case that will do that (actually I did) and if not handled properly it just loops taking 100% cpu trying to reinject exception that cannot be handled. -- Gleb.