linux-kernel - Re: [PATCH v2 06/17] irqchip/gic-v3: Configure SGIs as standard interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <jhjimffgfyt.mognet@arm.com>
Date:   Thu, 25 Jun 2020 19:25:46 +0100
From:   Valentin Schneider <valentin.schneider@....com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Russell King <linux@....linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Sumit Garg <sumit.garg@...aro.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>, kernel-team@...roid.com
Subject: Re: [PATCH v2 06/17] irqchip/gic-v3: Configure SGIs as standard interrupts


On 24/06/20 20:58, Marc Zyngier wrote:
> Change the way we deal with GICv3 SGIs by turning them into proper
> IRQs, and calling into the arch code to register the interrupt range
> instead of a callback.
>
> Signed-off-by: Marc Zyngier <maz@...nel.org>
> ---
>  drivers/irqchip/irq-gic-v3.c | 81 +++++++++++++++++++-----------------
>  1 file changed, 43 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 19b294ed48ba..d275e9b9533d 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -36,6 +36,8 @@
>  #define FLAGS_WORKAROUND_GICR_WAKER_MSM8996	(1ULL << 0)
>  #define FLAGS_WORKAROUND_CAVIUM_ERRATUM_38539	(1ULL << 1)
>
> +#define GIC_IRQ_TYPE_PARTITION	(GIC_IRQ_TYPE_LPI + 1)
> +

Nit: this piqued my interest but ended up being just a define shuffle; As a
member of the git speleologists' guild, I'd be overjoyed with having a
small notion of that in the changelog.

>  struct redist_region {
>       void __iomem		*redist_base;
>       phys_addr_t		phys_base;
> @@ -657,38 +659,14 @@ static asmlinkage void __exception_irq_entry gic_handle_irq(struct pt_regs *regs
>       if ((irqnr >= 1020 && irqnr <= 1023))
>               return;
>
> -	/* Treat anything but SGIs in a uniform way */
> -	if (likely(irqnr > 15)) {
> -		int err;
> -
> -		if (static_branch_likely(&supports_deactivate_key))
> -			gic_write_eoir(irqnr);
> -		else
> -			isb();
> -
> -		err = handle_domain_irq(gic_data.domain, irqnr, regs);
> -		if (err) {
> -			WARN_ONCE(true, "Unexpected interrupt received!\n");
> -			gic_deactivate_unhandled(irqnr);
> -		}
> -		return;
> -	}
> -	if (irqnr < 16) {
> +	if (static_branch_likely(&supports_deactivate_key))
>               gic_write_eoir(irqnr);
> -		if (static_branch_likely(&supports_deactivate_key))
> -			gic_write_dir(irqnr);
> -#ifdef CONFIG_SMP
> -		/*
> -		 * Unlike GICv2, we don't need an smp_rmb() here.
> -		 * The control dependency from gic_read_iar to
> -		 * the ISB in gic_write_eoir is enough to ensure
> -		 * that any shared data read by handle_IPI will
> -		 * be read after the ACK.
> -		 */

Isn't that still relevant?

Also, while staring at this it dawned on me that IPI's don't need the
eoimode=0 isb(): due to how the IPI flow-handler is structured, we'll get a
gic_eoi_irq() just before calling into the irqaction. Dunno how much we
care about it.

> -		handle_IPI(irqnr, regs);
> -#else
> -		WARN_ONCE(true, "Unexpected SGI received!\n");
> -#endif
> +	else
> +		isb();
> +
> +	if (handle_domain_irq(gic_data.domain, irqnr, regs)) {
> +		WARN_ONCE(true, "Unexpected interrupt received!\n");
> +		gic_deactivate_unhandled(irqnr);
>       }
>  }
>