From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch 1/2] KVM: x86: handle double and triple faults for every exception Date: Sun, 15 Nov 2009 16:34:55 +0200 Message-ID: <4B00118F.4080604@redhat.com> References: <20091111192947.348198723@localhost.localdomain> <20091111193837.115825934@localhost.localdomain> <20091112122659.GC7392@redhat.com> <4AFFF716.5000708@redhat.com> <20091115125146.GF7392@redhat.com> <4AFFFE1A.9090203@redhat.com> <4B001031.60508@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gleb Natapov , Marcelo Tosatti , kvm@vger.kernel.org, jan.kiszka@siemens.com, joerg.roedel@amd.com To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:47774 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753134AbZKOOex (ORCPT ); Sun, 15 Nov 2009 09:34:53 -0500 In-Reply-To: <4B001031.60508@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 11/15/2009 04:29 PM, Jan Kiszka wrote: > Avi Kivity wrote: > >> On 11/15/2009 02:51 PM, Gleb Natapov wrote: >> >>> >>>> "replacing" exceptions is dangerous in the case of debug exceptions >>>> and machine checks, since restarting execution won't recover them. >>>> >>>> >>>> >>> But not replacing them is not better. No point in re-injecting >>> exception that causes another exception. >>> >>> >> Right, just pointing out there's still a small hole left. Replacing is >> much better ignoring. >> > Is the hardware doing some queuing in this case? Gleb has verified by testing, and Intel has confirmed, that the hardware does not queue, and will in fact lose traps and NMIs in such a case. So the small hole is actually present in the processor and we're better off not queueing! I've forgotten about this but Gleb reminded me. > Would it be overly > complicated to adopt the real behavior here? > Not only would it be difficult, it would also be incorrect. -- error compiling committee.c: too many arguments to function