Re: [Xen-devel] NMI deferral on i386

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> Keir Fraser <keir@xxxxxxxxxxxxx> 16.05.07 14:32 >>>
>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.

Yes, that's what I mean. And I'm not so much concerned about turning a (very
rare) 'nice' crash into an 'ugly' one, but more about that fact that until the
system actually crashes it may continue to execute for a short while, possibly
making the data corruption situation worse.

>Personally I've never seen a #MC or had one reported to me, restartable or
>not. Maybe I'm lucky. :-)

I did see quite a few non-restartable ones (on native Linux), and it took me
some time to actually get the system into a state where I could see the
related messages before it rebooted. I don't have that system anymore,
though, otherwise I might be have been able to use it for testing purposes
here.

Jan


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