Re: [Xen-devel] [PATCH] x86: machine check exception handling

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

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