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

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



>> >> 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.

Jan


_______________________________________________
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®.