From: "Jan Beulich" <jbeulich@novell.com>
To: Keir Fraser <keir@xensource.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] x86: machine check exception handling
Date: Fri, 22 Jun 2007 08:01:38 +0100 [thread overview]
Message-ID: <467B8FF2.76E4.0078.0@novell.com> (raw)
In-Reply-To: <C2A04698.11088%keir@xensource.com>
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@xensource.com> 21.06.07 16:15 >>>
On 19/6/07 11:06, "Jan Beulich" <jbeulich@novell.com> 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
next prev parent reply other threads:[~2007-06-22 7:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-19 10:06 [PATCH] x86: machine check exception handling Jan Beulich
2007-06-21 14:15 ` Keir Fraser
2007-06-21 14:38 ` Christoph Egger
2007-06-21 14:59 ` Keir Fraser
2007-06-25 11:07 ` Christoph Egger
2007-06-22 6:57 ` Jan Beulich
2007-06-22 7:15 ` Keir Fraser
2007-06-22 7:47 ` Jan Beulich
2007-06-22 7:52 ` Keir Fraser
2007-06-22 7:59 ` Keir Fraser
2007-06-22 7:01 ` Jan Beulich [this message]
2007-06-22 7:16 ` Keir Fraser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=467B8FF2.76E4.0078.0@novell.com \
--to=jbeulich@novell.com \
--cc=keir@xensource.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.