WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [RFC] RAS(Part II)--MCA enalbing in XEN

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>