Re: [PATCH 5/5] irqchip/sifive-plic: Separate the enable and mask operations

From: Marc Zyngier <maz@kernel.org>
To: Samuel Holland <samuel@sholland.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Guo Ren <guoren@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Russell King <linux@armlinux.org.uk>,
	Wei Xu <xuwei5@hisilicon.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH 5/5] irqchip/sifive-plic: Separate the enable and mask operations
Date: Tue, 10 May 2022 11:27:17 +0100	[thread overview]
Message-ID: <87a6bp7ke2.wl-maz@kernel.org> (raw)
In-Reply-To: <20220509034333.60017-6-samuel@sholland.org>

On Mon, 09 May 2022 04:43:33 +0100,
Samuel Holland <samuel@sholland.org> wrote:
> 
> The PLIC has two per-IRQ checks before sending an IRQ to a hart context.
> First, it checks that the IRQ's priority is nonzero. Then, it checks
> that the enable bit is set for that combination of IRQ and context.
> 
> Currently, the PLIC driver sets both the priority value and the enable
> bit in its (un)mask operations. However, modifying the enable bit is
> problematic for two reasons:
>   1) The enable bits are packed, so changes are not atomic and require
>      taking a spinlock.
>   2) The following requirememnt from the PLIC spec, which explains the
>      racy (un)mask operations in plic_irq_eoi():
> 
>        If the completion ID does not match an interrupt source
>        that is currently enabled for the target, the completion
>        is silently ignored.
> 
> Both of these problems are solved by using the priority value to mask
> IRQs. Each IRQ has a separate priority register, so writing the priority
> value is atomic. And since the enable bit remains set while an IRQ is
> masked, the EOI operation works normally. The enable bits are still used
> to control the IRQ's affinity.

This is pretty neat.

My only concern is around whether implementations do when changing
priority of enabled interrupts. The PLIC architecture is conveniently
silent on the subject, but that's certainly something that can result
in total crap with the ARM GICs, for example, because an
implementation is free to apply this priority change on an already
pending interrupt, or not. But the kernel really wants the interrupt
to be masked once it tells the HW to do so.

Could anyone please check the RTL for some common implementations?

A way to avoid the above trouble (should it exist) would be to
disable the interrupt when changing the priority, and then reenable
it. You'd still get the simpler EOI, which is what you really want.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel