From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: NMI deferral on i386 Date: Wed, 16 May 2007 13:32:06 +0100 Message-ID: References: <464AF4A9.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <464AF4A9.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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. > > 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. Personally I've never seen a #MC or had one reported to me, restartable or not. Maybe I'm lucky. :-) -- Keir