From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: NMI deferral on i386 Date: Wed, 16 May 2007 09:28:22 +0100 Message-ID: References: <464ADA4F.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: <464ADA4F.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 09:17, "Jan Beulich" wrote: >> Yes, it's good enough for watchdog and oprofile. Level-triggered external >> NMIs will of course be a problem. We could possibly work around this by >> masking LINT1 if we are CPU0 (and, of course, if LAPIC is enabled) and then >> unmasking only at the end of real NMI handler. And of course x86/64 doesn't >> have this problem at all, and practically speaking is pretty much the only >> hypervisor build that vendors seem to care about. > > What if we removed the deferral altogether, and made the NMI handler > store into the outer most frame (after all, selector registers have fixed > places on that frame), marking the that frame accordingly so that > overwriting the values saved this way can be avoided in the > interrupted save sequence (would be necessary only if both %ds and > %es are neither __HYPERVISOR_DS nor null [neatly avoiding special > casing the vm86 mode entry in the outer frame], and would add an extra > branch to __SAVE_ALL_PRE plus splitting the selector register stores > into moving %ds and %es into general purpose registers, testing the > flag NMI or MCE handlers may set, and storing the GPRs into the frame > if the flag was clear). 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. -- Keir