All of lore.kernel.org
 help / color / mirror / Atom feed
From: marc.zyngier@arm.com (Marc Zyngier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] irqchip-gicv3: wait for ack from redistributer after read_iar
Date: Thu, 4 Feb 2016 09:32:03 +0000	[thread overview]
Message-ID: <56B31A93.5050608@arm.com> (raw)
In-Reply-To: <1454528588-32721-1-git-send-email-tchalamarla@caviumnetworks.com>

Tirumalesh,

On 03/02/16 19:43, tchalamarla at caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
> 
> Systems with high number of cores and sufficiently loaded,
> there exists a small window where it is possible for re-distributor
> to illegally merge two LPI and cuases missing interrupts.

s/cuases/causes/

It has nothing to do with the number of cores or the load, but
everything to do with the latency between the CPU interface and the
redistributor, and how quickly the redistributor gets notified that the
interrupt is not pending anymore.

> 
> Solution is, wait for ack from the redistributor after read_iar.
> A "dsb sy" after IAR read ensures there is no illegal merge windows.

You don't "wait for the ack". You actually *push* the ack (as in
Interrupt Acknowledgement Register) towards the redistributor.

The fact that the DSB generates an ACK message from the redistributor is
an HW implementation detail is not universally relevant. Please stay at
the architecture level, and avoid implementation details.

> 
> giv3 spec version 32 also warns this, see section 4.4.13

What is the point of pointing to an engineering specification that is
unavailable to almost anyone (hint: it has the word "Confidential" on
each and every page)?

A much better reference would be a quote from the publicly available GIC
Architecture Specification (ARM IHI 0069B). Something like:

4.1.1 Physical CPU Interface:
"The effects of reading ICC_IAR0_EL1 and ICC_IAR1_EL1 on the state of a
returned INTID are not guaranteed to be visible until after the
execution of a DSB."

> 
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
> ---
>  arch/arm64/include/asm/arch_gicv3.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/include/asm/arch_gicv3.h b/arch/arm64/include/asm/arch_gicv3.h
> index 2731d3b..8ec88e5 100644
> --- a/arch/arm64/include/asm/arch_gicv3.h
> +++ b/arch/arm64/include/asm/arch_gicv3.h
> @@ -103,6 +103,7 @@ static inline u64 gic_read_iar_common(void)
>  	u64 irqstat;
>  
>  	asm volatile("mrs_s %0, " __stringify(ICC_IAR1_EL1) : "=r" (irqstat));
> +	dsb(sy);
>  	return irqstat;
>  }
>  
> 

Other than that, I'm fine with this. Please repost with an amended
commit message and subject.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <marc.zyngier@arm.com>
To: tchalamarla@caviumnetworks.com, linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] irqchip-gicv3: wait for ack from redistributer after read_iar
Date: Thu, 4 Feb 2016 09:32:03 +0000	[thread overview]
Message-ID: <56B31A93.5050608@arm.com> (raw)
In-Reply-To: <1454528588-32721-1-git-send-email-tchalamarla@caviumnetworks.com>

Tirumalesh,

On 03/02/16 19:43, tchalamarla@caviumnetworks.com wrote:
> From: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
> 
> Systems with high number of cores and sufficiently loaded,
> there exists a small window where it is possible for re-distributor
> to illegally merge two LPI and cuases missing interrupts.

s/cuases/causes/

It has nothing to do with the number of cores or the load, but
everything to do with the latency between the CPU interface and the
redistributor, and how quickly the redistributor gets notified that the
interrupt is not pending anymore.

> 
> Solution is, wait for ack from the redistributor after read_iar.
> A "dsb sy" after IAR read ensures there is no illegal merge windows.

You don't "wait for the ack". You actually *push* the ack (as in
Interrupt Acknowledgement Register) towards the redistributor.

The fact that the DSB generates an ACK message from the redistributor is
an HW implementation detail is not universally relevant. Please stay at
the architecture level, and avoid implementation details.

> 
> giv3 spec version 32 also warns this, see section 4.4.13

What is the point of pointing to an engineering specification that is
unavailable to almost anyone (hint: it has the word "Confidential" on
each and every page)?

A much better reference would be a quote from the publicly available GIC
Architecture Specification (ARM IHI 0069B). Something like:

4.1.1 Physical CPU Interface:
"The effects of reading ICC_IAR0_EL1 and ICC_IAR1_EL1 on the state of a
returned INTID are not guaranteed to be visible until after the
execution of a DSB."

> 
> Signed-off-by: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
> ---
>  arch/arm64/include/asm/arch_gicv3.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/include/asm/arch_gicv3.h b/arch/arm64/include/asm/arch_gicv3.h
> index 2731d3b..8ec88e5 100644
> --- a/arch/arm64/include/asm/arch_gicv3.h
> +++ b/arch/arm64/include/asm/arch_gicv3.h
> @@ -103,6 +103,7 @@ static inline u64 gic_read_iar_common(void)
>  	u64 irqstat;
>  
>  	asm volatile("mrs_s %0, " __stringify(ICC_IAR1_EL1) : "=r" (irqstat));
> +	dsb(sy);
>  	return irqstat;
>  }
>  
> 

Other than that, I'm fine with this. Please repost with an amended
commit message and subject.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2016-02-04  9:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03 19:43 [PATCH] irqchip-gicv3: wait for ack from redistributer after read_iar tchalamarla at caviumnetworks.com
2016-02-03 19:43 ` tchalamarla
2016-02-04  9:32 ` Marc Zyngier [this message]
2016-02-04  9:32   ` Marc Zyngier

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=56B31A93.5050608@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.