[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86: machine check exception handling
Sadly I must agree. I have empirical evidence that 1kB is not enough for the #DF handler. Please knock up up a patch. -- Keir On 22/6/07 08:01, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote: > Btw., there's another thing I'm concerned about (and I meant to add this to > the patch description, but forgot): All the IST-exceptions now have mere 1k > of stack space, which seems pretty low. I'd really think we should bump this > to 4k, at the expense of wasting some memory by bumping the stack order. > > Jan > >>>> Keir Fraser <keir@xxxxxxxxxxxxx> 21.06.07 16:15 >>> > On 19/6/07 11:06, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote: > >> Properly handle MCE (connecting the exisiting, but so far unused vendor >> specific handlers). HVM guests don't own CR4.MCE (and hence can't >> suppress the exception) anymore, preventing silent machine shutdown. >> >> This patch won't apply or work without the patch removing i386's NMI >> deferral. > > Applied with the following changes: > 1. Pulled out the common parts of the NMI/MCE asm handlers into a common > subroutine (like all other execption handlers jump at handle_exception to do > the hard work). > 2. Kept do_machine_check() as analog of do_nmi(), which can hide > machine_check_vector definition (and hence I removed all changes inside > arch/x86/cpu/mcheck). I'd like to keep do_machine_check(), even if it > remains no more than a direct call at machine_check_vector(). We could clean > up machine_check_vector() as a separate patch -- not sure if it's worth it > right now, and maybe we're better off keeping close to original Linux files? > 3. Most contentious, I'm sure: removed VMX changes that would keep > interrupts disabled across NMI/MCE. The reason is simply that SVM does not > bother with this. If there is a requirement that NMI/MCE be called with > particular constraints on EFLAGS, then we should make that clear and fix up > both VMX and SVM in a separate patch. The pain of this is that it would > probably require extra checks on critical vmexit paths. Is it *really* that > bad for #MC to get interrupted? > > -- Keir > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |