[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Frank.Vanderlinden@xxxxxxx <mailto:Frank.Vanderlinden@xxxxxxx> wrote:
> Kleen, Andi wrote:
>>> Kleen, Andi wrote:
>> 
>> So it's generally better to inject generic events, not just blindly
>> forward. 
>> 
> 
> Agreed. I can see advantages to the vMCE code, but it has to deliver
> something to the domU that makes it do something reasonable.
> That's why
> I have some doubts about the patch that was sent, it doesn't
> quite seem
> to achieve that (certainly not without translating the address).
> 
> - Frank

Yes, we should have include the translation. We didn't do that when sending out 
the patch because we thought the PV guest has idea of m2p translation. Later we 
realized the translation is needed for PV guest after more consideration, since 
the unmodified #MC handler will use guest address. Of course we always need the 
translation for HVM guest, which however is not in that patch's scope . Sorry 
for any confusion caused.

One thing need notice is, the information passed through vIRQ is physical 
information while dom0s' MCA handler will get guest information, so user space 
tools should be aware of such constraints.

So, Frank/Egger, can I assume followed are consensus currently?

1) MCE is handled by Xen HV totally, while guest's vMCE handler will only works 
for itself. 
2) Xen present a virtual #MC to guest through MSR access emulation.(Xen will do 
the translation if needed).
3) Guest's unmodified MCE handler will handle the vMCE injected. 
4) Dom0 will get all log/telemetry through hypercall. 
5) The action taken by xen will be passed to dom0 through the telemetry 
mechanism.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.