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
|