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

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

On Wednesday 06 June 2007 14:25:26 Gavin Maltby wrote:
> Hi,
>
> On 06/06/07 12:57, Christoph Egger wrote:
> >>>> For the first I've assumed so far that an event channel notification
> >>>> of the MCA event will suffice;  as long as the hypervisor only polls
> >>>> for correctable MCA errors at a low-frequency rate (currently 15s
> >>>> interval) there is no danger of spamming that single notification.
> >>>
> >>> Why polling?
> >>
> >> Polling for correctable errors, but #MC as usual for others.  Setting
> >> MCi_CTL bits for correctable errors does not produce a machine check,
> >> so polling is the only approach unless one sets additional (and
> >> undocumented, certainly for AMD chips) config bits.  What I was getting
> >> at here is that polling at largish intervals for correctables is
> >> the correct approach - trapping for them or polling at a high-frequency
> >> is bad because in cases where you have some form of solid correctable
> >> error (say a single bad pin in a dimm socket affecting one or two ranks
> >> of that dimm but never able to produce a UE) the trap handling and
> >> diagnosis software consume the machine and things make little useful
> >> forward progress.
> >
> > I still don't see, why #MC for all kind of errors is bad.
>
> I'm talking about whether the hypervisor takes a machine check
> for an error or polls for it.  We do not want #MC for correctable
> errors stopping the hypervisor from making progress.  And if the
> hypervisor poll interval was to small a solid error would again
> keep the hypervisor busy producing (mostly/all duplicate)
> error telemetry and the diagnosis code in dom0 would burn
> cpu cycles, too.
>
> How errors observed by the hypervisor, be they from #MC or from
> a poll, are propogated to the domains is unimportant from this
> point of view - e.g., if we decide to take error telemetry
> discovered via a poll in the hypervisor and propogate it
> to the domain pretending it is undistinguishable from a machine
> check that will not hurt or limit the domain processing.
>
> An untested design I had in mind, unashamedly influenced by what
> we do in Solaris, was to have some common memory shared between
> hypervisor and domain into which the hypervisor produces
> error telemetry and the domain consumes that telemetry.

That is the struct vcpu_info in the PUBLIC xen.h. It is accessable
in the hypervisor as well as in the guest.

> Producing and consuming is lockless using compare-and-swap.
> There are two queues in this shared memory - one for uncorrectable
> error telemetry and one for correctable error telemetry.  When the
> domain gets whatever event to notify it of telemetry for processing
> it processes the queues;  the event would be synchronous for
> uncorrectable errors (ie, domain must process the telemetry
> right now) or asynchronous in the case of correctable errors
> (process when convenient).  The separation of CE and UE queues
> stops CEs from flooding the more important UE events (you can
> always drop CEs if there is no more space, but you can never
> drop UEs).

So we use the asynchronous event mechanism VIRQ_DOM_EXC to report
correctable errors to the Dom0 and the nmi stuff for uncorrectable errors to
Dom0 and DomU, right?

The fact that VIRQ_DOM_EXC is for Dom0 only doesn't hurt here, since we never 
report CEs to DomUs.


> [cut]
>
> > After some code reading I found a nmi_pending, nmi_masked and nmi_addr in
>
> [cut]
>
> Still chewing on that ...


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