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

[Christoph Egger <Christoph.Egger@amd.com>]

On Wednesday 25 February 2009 03:25:12 Jiang, Yunhong wrote:
> Frank.Vanderlinden@Sun.COM <mailto:Frank.Vanderlinden@Sun.COM> 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.

Mostly. Regarding 2) I want like to discuss first how to handle errors
impacting multiple contiguous physical pages which are non-contigous
in guest physical space.

And I also want to discuss about how to do recovery actions requiring
PCI access. One example for this is
Shanghai's "L3 Cache Index Disable"-Feature.
Xen delegates PCI config space to Dom0 and
via PCI passthrough partly to DomU.
That means, if registers in PCI config space are independently
accessable by Xen, Dom0 and/or DomU, they can interfere with each other.
Therefore, we need to
a) clearly define who handles what and
b) define some rules based on a)
c) discuss how to handle Dom0/DomU going wild
    and break the rules defined in b)


Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632