[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] NMI deferral on i386

  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Wed, 16 May 2007 13:32:06 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 16 May 2007 05:30:42 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AceXtjaldPdG9QOpEdyPGgAX8io7RQ==
  • Thread-topic: [Xen-devel] NMI deferral on i386

On 16/5/07 11:10, "Jan Beulich" <jbeulich@xxxxxxxxxx> 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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.