| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] NMI deferral on i386
>>> Keir Fraser <keir@xxxxxxxxxxxxx> 15.05.07 17:00 >>>
>On 15/5/07 15:46, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> - by using iret, the NMI is being acknowledged to the CPU, and since nothing
>> was done to address its reason, I can't see why it shouldn't re-trigger
>> right after that iret (unless it was sent as an IPI)
>
>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).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home