| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] NMI deferral on i386
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.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home