Re: [Xen-devel] NMI deferral on i386

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir@xxxxxxxxxxxxx> 16.05.07 10:28 >>>
>On 16/5/07 09:17, "Jan Beulich" <jbeulich@xxxxxxxxxx> 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.

I think I found a pretty reasonable solution, which I'm attaching in its current
(3.1-based) form, together with the prior (untested) variant that copied the
NMI behavior. Even if it doesn't apply to -unstable, I'd be glad if you could
have a brief look to see whether you consider the approach too intrusive (in
which case there would be no point in trying to bring it forward to -unstable).

Jan

Attachment: x86-machine-check.patch.0
Description: Binary data

Attachment: x86-machine-check.patch
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel