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

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Christoph Egger
> Sent: 01 June 2007 09:12
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Gavin Maltby
> Subject: Re: [Xen-devel] RFC: MCA/MCE concept
> 
> On Wednesday 30 May 2007 17:03:55 Petersson, Mats wrote:
> > [snip]
> >
> > > My feeling is that the hypervisor and dom0 own the hardware
> > > and as such
> > > all hardware fault management should reside there.  So we 
> should never
> > > deliver any form of #MC to a domU, nor should a poll of 
> MCA state from
> > > a domU ever observe valid state (e.g, make the RDMSR return 0).
> > > So all handling, logging and diagnosis as well as hardware
> > > response actions
> > > (such as to deploy an online spare chip-select) are controlled
> > > in the hypervisor/dom0 combination.  That seems a consistent
> > > model - e.g.,
> > > if a domU is migrated to another system it should not carry the
> > > diagnosis state of the original system across etc, since that
> > > belongs with
> > > the one domain that cannot migrate.
> >
> > I agree entirely with this.
> >
> > > But that is not to say that (I think at a future phase) domU
> > > should not
> > > participate in a higher-level fault management function, at
> > > the direction
> > > of the hypervisor/dom0 combo.  For example if/when we can 
> isolate an
> > > uncorrectable error to a single domU we could forward 
> such an event to
> > > the affected domU if it has registered its 
> ability/interest in such
> > > events.  These won't be in the form of a faked #MC or anything,
> > > instead they'd be some form of synchronous trap 
> experienced when next
> > > the affected domU context resumes on CPU.  The intelligent
> > > domU handler
> > > can then decide whether the domU must panic, whether it 
> could simply
> > > kill the affected process etc.  Those details are clearly
> > > sketchy, but the
> > > idea is to up-level the communication to a domU to be more like
> > > "you're broken" rather than "here's a machine-level 
> hardware error for
> > > you to interpret and decide what to do with".
> >
> > Yes, this makes much more sense than forwarding #MC, as the 
> guest would
> > have a hard time to actually do anything really useful with 
> this. As far
> > as I know, most uncorrectable errors are near enough 
> entirely fatal in
> > most commercial non-Enterprise OS's anyways - e.g. in Windows XP or
> > Server 2K3, it always ends in a blue-screen - which is 
> hardly any better
> > than the guest being "humanely euthenazed" by Dom0.
> >
> > I take it this would be some sort of hypercall (available 
> through the
> > regular PV-driver interface for HVM guests) to say "Let me 
> know if I'm
> > broken - trap on vector X".
> 
> 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].

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. 

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

--
Mats

> 
> > --
> > Mats
> >
> > > Gavin
> > >
> 
> -- 
> 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
> 
> 
> 



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