From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] x86: machine check exception handling Date: Fri, 22 Jun 2007 08:47:06 +0100 Message-ID: <467B9A9A.76E4.0078.0@novell.com> References: <467B8EF2.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 22.06.07 09:15 >>> >On 22/6/07 07:57, "Jan Beulich" wrote: > >>> 3. Most contentious, I'm sure: removed VMX changes that would keep >>> interrupts disabled across NMI/MCE. The reason is simply that SVM does = not >>> bother with this. If there is a requirement that NMI/MCE be called = with >>> particular constraints on EFLAGS, then we should make that clear and = fix up >>> both VMX and SVM in a separate patch. The pain of this is that it = would >>> probably require extra checks on critical vmexit paths. Is it *really* = that >>> bad for #MC to get interrupted? >>=20 >> Yes, I think it is bad - the machine is known to be a in bad condition >> already, >> and by allowing external interrupts you make the situation even worse. >> Consequently I think SVM should be fixed to only conditionally enable >> interrupts, just like VMX does. > >What issue do you think ExtInts will introduce? A crash before we get a >fatal error dump onto the Xen console? This argument seems more than a >little dubious to me. Why - such a crash would be *very* difficult to debug, as you likely = wouldn't be able to guess the original reason. > But if we want to complicate the CLI/STI logic of VMX >and SVM then I think we should do that by pushing STI/CLI (or STGI/CLGI) >handling into the individual cases of the main demux switch statements in >vmx.c and svm.c. Jan