|   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 availableRe: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN, Frank van der Linden
Message not availableRe: [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
 |  |  |