From: "Chen, Tiejun" <tiejun.chen@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: andrew.cooper3@citrix.com, keir@xen.org, xen-devel@lists.xen.org
Subject: Re: [RFC][PATCH] xen/apic: refactor error_interrupt
Date: Mon, 04 May 2015 19:14:59 +0800 [thread overview]
Message-ID: <554754B3.8090104@intel.com> (raw)
In-Reply-To: <554744EC0200007800076298@mail.emea.novell.com>
On 2015/5/4 16:07, Jan Beulich wrote:
>>>> On 04.05.15 at 04:03, <tiejun.chen@intel.com> wrote:
>> --- a/xen/arch/x86/apic.c
>> +++ b/xen/arch/x86/apic.c
>> @@ -1319,28 +1319,37 @@ out: ;
>> * This interrupt should never happen with our APIC/SMP architecture
>> */
>>
>> +static const char *apic_fault_reasons[] =
>
> If at all, then this should be const. But...
>
>> +{
>> + "Send CS error",
>> + "Receive CS error",
>> + "Send accept error",
>> + "Receive accept error",
>> + "Reserved",
>> + "Send illegal vector",
>> + "Received illegal vector",
>> + "Illegal register address",
>> +};
>> +
>> +static const char *apic_get_fault_reason(u8 fault_reason)
>> +{
>> + return apic_fault_reasons[fault_reason];
>> +}
>> +
>> void error_interrupt(struct cpu_user_regs *regs)
>> {
>> unsigned long v, v1;
>> + const char *reason;
>>
>> /* First tickle the hardware, only then report what went on. -- REW */
>> v = apic_read(APIC_ESR);
>> apic_write(APIC_ESR, 0);
>> v1 = apic_read(APIC_ESR);
>> ack_APIC_irq();
>> + reason = apic_get_fault_reason(ffs(v1) - 1);
>
> ... I'm not convinced - you're treating errors represented by lower
> bits "better" than higher ones. And if there are multiple errors, then
> spelling out one but not the other may end up being confusing.
I just think APIC shouldn't record these multiple errors at the same
time because these kinds of errors seem be exclusive... But I don't find
this is described in SDM so I think you're right.
Fortunately, looks Andrew guides me a approach to cover this point, so
just let me go there.
Thanks
Tiejun
> These errors should be rare enough to warrant manually looking up
> the individual bits' meanings.
>
> Jan
>
>> - /* Here is what the APIC error bits mean:
>> - 0: Send CS error
>> - 1: Receive CS error
>> - 2: Send accept error
>> - 3: Receive accept error
>> - 4: Reserved
>> - 5: Send illegal vector
>> - 6: Received illegal vector
>> - 7: Illegal register address
>> - */
>> - printk (KERN_DEBUG "APIC error on CPU%d: %02lx(%02lx)\n",
>> - smp_processor_id(), v , v1);
>> + printk (KERN_DEBUG "APIC error on CPU%d: %02lx(%02lx):%s.\n",
>> + smp_processor_id(), v , v1, reason);
>> }
>>
>> /*
>
>
>
>
next prev parent reply other threads:[~2015-05-04 11:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-04 2:03 [RFC][PATCH] xen/apic: refactor error_interrupt Tiejun Chen
2015-05-04 8:07 ` Jan Beulich
2015-05-04 11:14 ` Chen, Tiejun [this message]
2015-05-04 8:25 ` Andrew Cooper
2015-05-05 4:46 ` Chen, Tiejun
2015-05-05 6:02 ` Andrew Cooper
2015-05-05 6:28 ` Chen, Tiejun
2015-05-05 6:49 ` Andrew Cooper
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=554754B3.8090104@intel.com \
--to=tiejun.chen@intel.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.