All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Chen, Tiejun" <tiejun.chen@intel.com>, keir@xen.org, jbeulich@suse.com
Cc: xen-devel@lists.xen.org
Subject: Re: [RFC][PATCH] xen/apic: refactor error_interrupt
Date: Tue, 05 May 2015 07:49:02 +0100	[thread overview]
Message-ID: <554867DE.9000500@citrix.com> (raw)
In-Reply-To: <55486311.9040505@intel.com>

On 05/05/2015 07:28, Chen, Tiejun wrote:
> On 2015/5/5 14:02, Andrew Cooper wrote:
>> On 05/05/2015 05:46, Chen, Tiejun wrote:
>>>
>>>> A better approach might be:
>>>>
>>>> printk(KERN_DEBUG "APIC error on CPU%u: %02lx(%02lx)", ...)
>>>> for ( i = (1<<7); i; i >>= 1 )
>>>>     if ( v1 & i )
>>>>       printk(", %s", apic_fault_reasons[i]);
>>>
>>> I guess this should be apic_fault_reasons[ffs(i) - 1].
>>
>> Indeed.
>>
>>>
>>>> printk("\n");
>>>>
>>>> Which will decode all set bits, and guarantee not to access outside
>>>> the
>>>> bounds of apic_fault_reasons.
>>>>
>>>
>>> Thanks you for all comments. So overall, what about this?
>>
>> Much better.  A few further comments.
>>
>>>
>>> diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
>>> index 3217bdf..87684a2 100644
>>> --- a/xen/arch/x86/apic.c
>>> +++ b/xen/arch/x86/apic.c
>>> @@ -1319,9 +1319,21 @@ out: ;
>>>    * This interrupt should never happen with our APIC/SMP architecture
>>>    */
>>>
>>> +static const char * const fault_reasons_from_esr[] =
>>
>> It is not too important, but I was thinking of something rather shorter
>> as a name.  "esr_fields[]" perhaps ?
>
> Looks good.
>
>>
>>> +{
>>> +    "Send CS error",
>>> +    "Receive CS error",
>>> +    "Send accept error",
>>> +    "Receive accept error",
>>> +    "Redirectable IPI",
>>> +    "Send illegal vector",
>>> +    "Received illegal vector",
>>> +    "Illegal register address",
>>> +};
>>> +
>>>   void error_interrupt(struct cpu_user_regs *regs)
>>>   {
>>> -    unsigned long v, v1;
>>> +    unsigned int v, v1, i;
>>>
>>>       /* First tickle the hardware, only then report what went on. --
>>> REW */
>>>       v = apic_read(APIC_ESR);
>>> @@ -1329,18 +1341,12 @@ void error_interrupt(struct cpu_user_regs
>>> *regs)
>>>       v1 = apic_read(APIC_ESR);
>>>       ack_APIC_irq();
>>>
>>> -    /* 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",
>>> +    printk (KERN_DEBUG "APIC error on CPU%u: %02x(%02x)",
>>
>> While at this, please apply Xen style to all changed lines.  In
>> particular, drop the space between printk and its opening bracket.  Swap
>
> Okay. And actually we should clean this whole file completely since
> this is backported from Linux...

Not worth changing for the sake of changing, but where we are already
altering code we attempt to make it consistent.

>
>> KERN_ for XENLOG_
>
> Sure.
>
>>
>>>               smp_processor_id(), v , v1);
>>> +    for (i = (1<<7); i; i >>= 1)
>>
>> Spaces inside the brackets.
>>
>>> +        if(v1 & i)
>>
>> And here.
>>
>>> +            printk (KERN_DEBUG ", %s", fault_reasons_from_esr[ffs(i)
>>> - 1]);
>>
>> The code here now looks correct, but it is unlikely that the compiler
>> would be able to simplify the ffs() call.
>>
>> An alternate approach would be:
>>
>> int i;
>> for ( i = 7; i >= 0; --i )
>>      if ( v1 & (1 << i) )
>>           printk(... , fault_reasons_from_esr[i])
>
> Then,
>
> -    printk (KERN_DEBUG "APIC error on CPU%d: %02lx(%02lx)\n",
> +    printk(XENLOG_DEBUG "APIC error on CPU%u: %02x(%02x)",
>              smp_processor_id(), v , v1);
> +    for ( i = 7; i >= 0; --i )
> +        if ( v1 & (1 << i) )
> +            printk(XENLOG_DEBUG ", %s", esr_fields[i]);
>
>>
>>> +    printk (KERN_DEBUG ".\n");
>>
>> Please do not put full stops on messages like this.  It serves no useful
>> purpose, but wasted space in the console ring and wasted time when
>> pushed over a serial console.
>
> Are you saying this?
>
> printk(XENLOG_DEBUG "\n");

Yes, although you also need to drop the XENLOG_DEBUG from this and the
printk() inside the loop, as they are not printks from the start of a line.

so,
for ( i = 7; i >= 0; --i )
    if ( v1 & (1 << i) )
        printk(", %s", esr_fields[i]);
printk("\n");

~Andrew

      reply	other threads:[~2015-05-05  6:49 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
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 [this message]

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=554867DE.9000500@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tiejun.chen@intel.com \
    --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.