Frank.Vanderlinden@xxxxxxx <mailto:Frank.Vanderlinden@xxxxxxx> wrote:
> 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)
One notice is, we delieve vMCE to dom0/domU only when it is impacted. The idea
behind this is, MCE is handled by Xen HV totally, while guest's vMCE handler
will only works for itself. For example, when a page broken, Xen will firstly
mark the page offline in Xen side (i.e. take the recover action), then, it will
inject a vMCE to guest corresponding (dom0 or domU), the guest will kill the
application using the page, free the page, or do more action.
And we always pass the vIRQ to dom0 for logging and telemetry, user space tools
can take more proactive action for this if needed.
>
>
> 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
Agree that this modification is needed. Sorry we didn't reliaze the requirement
from Dom0 after reboot.
Either we can pass the action in the telemetry, or Dom0 can take action
specific method ,like retrieve the offlined page from Xen before reboot. If we
take the former, we may need a interface definition.
> 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.
What do you mean of the effect of wrmsr instruction. We need considering inject
#GP if invalid wrmsr , or remove the event when guest clear the MCi_STATUS_MCA
if needed. We send this RFC early to get feedback firstly for the design idea.
Or you mean more than this for the wrmsr?
>
> 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
Our purpose is guest has no idea it is running under xen as descripted above.
And what information do you think a normal guest's MCA handler needs to know,
and use the detailed physical information? After all, a guest cares only
itself. Also, maybe we can't provide PV handler for all guest (like windows).
Dom0 is a special case, it's vIRQ handler knows it is running under Xen, but
that is for log/telemetry and for proactive action.
> information on the system. In other words, the existing code
> that can be
What do you mean of "existing", our patch or current Xen implementation?
> 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..
I think the main advantage are:
a) We don't need maintain a PV MCA handler for guest, especially for HVM guest
b) We can get benifit from guest's MCA improvement/enhancement .
c) Applying this to dom0, we don't need different mechanism to dom0/hvm.
Thanks
Yunhong Jiang
>
> - Frank
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home