From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: NMI deferral on i386 Date: Wed, 16 May 2007 16:19:53 +0200 Message-ID: <464B2F29.76E4.0078.0@novell.com> References: <464AF4A9.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 16.05.07 14:32 >>> >On 16/5/07 11:10, "Jan Beulich" wrote: > >>> It sounds a bit painful. Also it's the exit-to-guest path that is more = of a >>> pain to deal with. In this case we may have restored a segment = register by >>> the time we take the NMI. What do we do in this case about restoring = the >>> segment register safely? Races in updating GDT/LDT may mean that the = reload >>> still may fault, even though it didn't just before; also we may need = to do >>> work in Xen (e.g., shadow-mode stuff) in interrupts-enabled context to = fix >>> up a #GP or #PG. >>=20 >> Indeed. Nevertheless, for non-restartable MCEs, deferral is impossible, = and >> hence some mechanism would still be needed (unless we say the machine's >> going down anyway in this case and we don't care about getting a proper >> reason logged). > >You mean, like with a #DF, that sometimes a #MC may have bogus CS:EIP and = so >you cannot IRET from it? I'm not sure how much we care about losing these >and turning a possibly-informative crash into an ugly and confusing = crash. Yes, that's what I mean. And I'm not so much concerned about turning a = (very rare) 'nice' crash into an 'ugly' one, but more about that fact that until = the system actually crashes it may continue to execute for a short while, = possibly making the data corruption situation worse. >Personally I've never seen a #MC or had one reported to me, restartable = or >not. Maybe I'm lucky. :-) I did see quite a few non-restartable ones (on native Linux), and it took = me some time to actually get the system into a state where I could see the related messages before it rebooted. I don't have that system anymore, though, otherwise I might be have been able to use it for testing purposes here. Jan