Re: [Xen-devel] RFC: MCA/MCE concept

["Christoph Egger" <Christoph.Egger@xxxxxxx>]

On Wednesday 30 May 2007 11:59:31 Jan Beulich wrote:
> >> >> Injecting an MCE to a hvm guest seems at least questionable. It can't
> >> >> really do anything about it (it doesn't even know the real topology
> >> >> of the system it's running on, so addresses stored in MSRs are
> >> >> meaningless - either you allow them to be read untranslated [in which
> >> >> case the guest cannot make sense of them] or you do translation for
> >> >> the guest [in which case it might make assumptions about co-locality
> >> >> of other nearby pages which will be wrong]).
> >> >
> >> >Yes, Xen should do the translation for the guest. The assumptions must
> >> >be fixed then. I know that's easier said than done.
> >>
> >> Exactly - you are proposing to fix all possible OSes, including
> >> sufficiently old ones. That's impossible. And I can't even see why an OS
> >> intended to run on native hardware would care to try to deal with
> >> virtualization aspects like this.
> >
> >I think, it was not obvious that
> >Xen should not inject failures into DomU that don't feature
> >a fault management. In this case, either Dom0 tells Xen what
> >to do with the DomU or Xen just kills the DomU.
>
> You apparently didn't get my point - even if the guest set up MCE properly
> (by setting CR4.MCE and possibly writing some MSRs) you cannot conclude
> that it is aware of the fact that it is running in a virtualized
> environment and that guest physical address relations do not map to machine
> physical address relations (i.e. a set of pages contiguous in gpa space is
> almost guaranteed to be discontiguous in mpa space). Hence if it is more
> than a single byte/cache line/page that is affected, any such assumptions
> made in the guest will be wrong.

Ah, I see. So HVM guests can only handle those errors where this assumption
is guaranteed to be correct. Xen needs to check the error type, the
address and the size (= address range) for this.
If Xen can't determine for sure, the guest can handle this right, then Xen has
to handle the DomU as a guest which does not feature fault management.


Christoph


-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel