This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] (v)MCE# injection

To: "Christoph Egger" <Christoph.Egger@xxxxxxx>, "Liping Ke" <liping.ke@xxxxxxxxx>, "Yunhong Jiang" <yunhong.jiang@xxxxxxxxx>
Subject: [Xen-devel] (v)MCE# injection
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Thu, 26 Nov 2009 08:51:28 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 26 Nov 2009 00:51:48 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I'm having the impression that this is significantly flawed at the moment,
and due to the number of issues I don't feel comfortable to submit a
patch without clarification on at least some of the aspects:

1) The outermost conditional in do_iret() compares against
VCPU_TRAP_NMI, which I would assume is a copy-and-paste mistake
and should really be VCPU_TRAP_MCE.

2) While c/s 19422 handled Dom0 only (and introduced some hardcoded
references to dom0), c/s 19871 relaxed the check to permit any domain,
but apparently failed to clean up the dom0 references.

3) I don't think the trap priority adjustment works properly at all, as
there's only provision for a single level of nesting (due to the old value
being stored in the vcpu structure), but the entry.S code would happily
nest an MCE inside an NMI. I think these rather need to be - just like in
physical CPUs - individual flags that tell whether an exception of that
kind is currently being processed. And I don't think either should mask
the other, the flags should just be used to prevent nested injection of
the same type of exception (but there needs to be a way to tell which
of the two was injected first, so the iret can clear the right flag).

4) The code in do_iret() doesn't seem to be 64-bit specific at all, i.e. I'd
think this should really be a common subroutine called from all three
do_iret() handlers (perhaps even including the trap priority and affinity


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>