|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] (v)MCE# injection
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
handling).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] (v)MCE# injection,
Jan Beulich <=
|
|
|
|
|