On Friday 01 June 2007 10:55:28 Petersson, Mats wrote:
[snip]
> > For short, guests with a PV MCA driver will see a certain event
> > (assuming the event mechanism will be used for the notification)
> > and guests w/o a PV MCA driver will see a "General Protection Fault".
> > Is that right?
>
> Not sure if GP fault is the right thing for non-"MCA PV driver" domains. I
> think "just killing" the domain is the right thing to do.
>
> We can't gurantee that a GP fault is actually going to "kill" the guest.
> Let's assume the code that ran on the guest was something along the lines
> of:
>
>
> int some_function(...)
> {
> ...
>
> try {
> ...
> /* Some code that does quite a lot of "random" processing that may
> cause, for example, GP fault */ ...
> } catch(Exception e)
> {
> ...
> /* handles GP fault within the kernel code */
> ...
> }
> }
>
>
> Note that Windows kernel drivers are allowed to use the kernel exception
> handling, and ARE allowed to "allow" GP faults if they wish to do so.
> [Don't ask me why MS allows this, but that's the case, so we have to live
> with it].
In that case, it will die sooner or later *after* consuming the data in error.
That means, the guest continues to live for an unknown time...
> I'm not sure if Linux, Solaris, *BSD, OS/2 or other OS's will allow
> "catching" a Kernel GP fault in a non-precise fashion (I know Linux has
> exception handling for EXACT positions in the code). But since at least one
> kernel DOES allow this, we can't be sure that a GPF will destroy the guest.
When Linux and *BSD see a GPF while they are in userspace, then they kill
the process with a SIGSEGV. If they are in kernelspace, then they panic.
> Second point to note is of course that if the guest is in user-mode when
> the GPF happens, then almost all OS's will just kill the application - and
> there's absolutely no reason to believe that the application running is
> necessarily where the actual memory problem is - it may be caused by memory
> scrubbing for example.
>
> Whatever we do to the guest, it should be a "certain death", unless the
> kernel has told us "I can handle MCE's".
It is obvious that there is no absolute generic way to handle all sort of
buggy guests. I vote for:
If DomU has a PV MCA driver use this or inject a GPF.
Multiplexing all the MSR's related to emulate MCA/MCE for the guests is much
more complex than just injecting a GPF - and slower.
Keir, what are your opinions on this thread?
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
|
Home