WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

Re: [Xen-ia64-devel] [RFC] MCA handler support for Xen/ia64

On Fri, 2006-07-28 at 21:12 +0900, Masaki Kanno wrote:
> Hi Alex,
> 
> We are awfully sorry to have kept you waiting for a long time.

Hi Kan,

   No problem, thanks for your thorough investigation into this.

> Our design is to inject all CMC/CPEs into dom0 vcpu0. I think this is 
> sufficient because our goal of this initial support is logging of 
> hardware error, not recovery. See detailed flow below.

   This looks good to me.  Queuing and tracking the interrupts could get
complicated, but I can't think of a better way to do it without going
back the the previous design of storing the error records in Xen.  Also
note that not all platforms support CPE interrupt, so you may need to
invent a slightly different flow for that case.  I would assume in this
case that Xen would poll each CPU for SAL_GET_STATE_INFO.  If it get
back an error log it adds that pCPU to a queue, and the next time dom0
calls SAL_GET_STATE_INFO it gets directed to the correct pCPU to re-read
the error log and clear it (much like your existing interrupt model).

> >   What about clearing error records?
> 
> By our new design, Xen issues SAL_CLEAR_STATE_INFO synchronizing with 
> SAL_CLEAR_STATE_INFO that dom0 issues.

   I like this approach better.

> >   Do you plan to support CMC and CPE throttling in Xen
> 
> Yes, our design is supported CMC and CPE throttling in Xen and dynamic 
> polling intervals. We think that Xen must not fall or slow down with 
> hot CMC and CPE interruption.

   Great!

> >   It may be overly complicated to support CPEI on dom0
> 
> Thanks for your advice. As for MADT and IOSAPIC, we are not well 
> informed. We hope for advice from you and everyone.
> Your advice modifies Linux/kernel(mca.c) of dom0, doesn't it? If so, 
> we modify Linux/kernel of dom0, and CPE supports polling mode only.

    I would start out with the easier case of letting dom0 poll for CPE
records.  This should require no change to dom0 MCA code, just make sure
a CPEI vector is not reported to dom0 via the ACPI MADT.

   We can then later investigate optimizations to make this more
efficient.  If we do something like a virtual IOSAPIC to deliver the CPE
interrupt, there shouldn't be any changes necessary to the dom0 MCA
code.  We just need to see how hard this would be (it may be easy).

> BTW, new member kaz has join our team.

   Welcome Kaz!  Thanks,

        Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.


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