xen-devel
Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN
To: |
"Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> |
Subject: |
Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN |
From: |
Frank van der Linden <Frank.Vanderlinden@xxxxxxx> |
Date: |
Fri, 20 Feb 2009 14:01:14 -0700 |
Cc: |
Gavin Maltby <Gavin.Maltby@xxxxxxx>, Christoph Egger <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Ke, Liping" <liping.ke@xxxxxxxxx> |
Delivery-date: |
Fri, 20 Feb 2009 13:01:54 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<E2263E4A5B2284449EEBD0AAB751098401C7AACC2B@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
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> |
References: |
<C5BF30B3.2C2B%keir.fraser@xxxxxxxxxxxxx> <200902181905.55015.Christoph.Egger@xxxxxxx> <E2263E4A5B2284449EEBD0AAB751098401C7AAC7A0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <200902191725.32556.Christoph.Egger@xxxxxxx> <E2263E4A5B2284449EEBD0AAB751098401C7AACC2B@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Thunderbird 2.0.0.17 (X11/20081023) |
I had some time to look over the patches in more detail and the previous
discussions that were referenced.
From your patches, what you write, and your slides, I gather the following:
* Corrected errors (found through polling and CMCI):
1) Collected error data (telemetry)
2) Inform dom0 through the VIRQ.
* Uncorrected errors:
1) See if any immediate action can be taken (CPU offline,
page retire)
2) Collect telemetry
3) Deliver vMCE to dom0 (and possibly domU)
I think it's fine that the hypervisor takes some immediate action in
some cases. It is good to do this as quickly as possible, and only the
hypervisor has all the information immediately available.
What would be needed for the Solaris framework, however, is to provide
information on what action was taken, along with the telemetry. As
Christoph noted, the Solaris FMA code checks, at bootup, if there were
components that previously had errors, and if so, it disables them again
to prevent further errors. To be able to do this, it needs the full
information not just on the error data, but also on any action taken by
the hypervisor, so that it can repeat this action. It may take some
modifications in the FMA code to account for the case where an action
has already been taken (to avoid trying to take conflicting action), but
I think that shouldn't be a big problem. Although I don't know that part
of our code very well.
The part that I still have doubts about, is the vMCE code. As far as I
can tell, it takes the information out of the MCA banks, and stores it,
per event, in a linked list. Per vMCE, the head of the list is taken and
used as an MSR context. The rdmsr instruction is trapped and redirected
to that information. It seems that the wrmsr instruction is accepted,
but has no effect (except that if the trap handler writes a value and
then reads it back again immediately, the values will be the same).
The main argument for the vMCE code seems to be that it allows existing
MCA handlers to be reused. However, I don't see the advantage in this.
Basically, it allows the handler to retrieve the MCA banks through plain
rdmsr instructions. Which is fine, but that's as far as it goes. Without
any additional information, that feature does not seem useful. wrmsr
instructions has no effect.
To take further action, the MCA code in dom0 (or a domU) needs to know
that it is running under Xen, and it needs to have detailed physical
information on the system. In other words, the existing code that can be
used is only the code that gathers some information. So, the only thing
that vMCE is good for, is that you can run unmodified error logging
code. But you can't interpret any of the error information further
without knowing more. Especially for a domU, which might not know
anything, this doesn't seem useful. What would the user of a domU do
with that information?
To recap, I think the part where Xen itself takes action is fine, with
some modifications. But I don't see any advantages in vMCE delivery,
unless I'm missing something of course..
- Frank
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, (continued)
- RE: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Jiang, Yunhong
- Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Christoph Egger
- RE: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Jiang, Yunhong
- Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Christoph Egger
- RE: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Jiang, Yunhong
- Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN,
Frank van der Linden <=
- RE: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Jiang, Yunhong
- Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Frank van der Linden
- Message not available
- Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Frank van der Linden
- Message not available
- Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Frank van der Linden
- RE: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Jiang, Yunhong
- Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Christoph Egger
- Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Frank van der Linden
- RE: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Jiang, Yunhong
- Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Gavin Maltby
- RE: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Jiang, Yunhong
|
|
|