|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
|
|
|
|