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

[Masaki Kanno <kanno.masaki@xxxxxxxxxxxxxx>]

Hi Alex,

Thanks for your comments and informations.
We start to make patch.

Best regards,
 You, Kaz, and Kan

>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