[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |