[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] RFC: MCA/MCE concept
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |