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

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