From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, broonie@kernel.org,
catalin.marinas@arm.com, will@kernel.org
Subject: Re: [PATCH 3/4] arm64: add ARM64_HAS_GIC_PRIO_NO_PMHE cpucap
Date: Mon, 23 Jan 2023 13:23:31 +0000 [thread overview]
Message-ID: <86bkmpmlkc.wl-maz@kernel.org> (raw)
In-Reply-To: <20230123124042.718743-4-mark.rutland@arm.com>
On Mon, 23 Jan 2023 12:40:41 +0000,
Mark Rutland <mark.rutland@arm.com> wrote:
>
> When Priority Mask Hint Enable (PMHE) == 0b1, the GIC may use the PMR
> value to determine whether to signal an IRQ to a PE, and consequently
> after a change to the PMR value, a DSB SY may be required to ensure that
> interrupts are signalled to a CPU in finite time. When PMHE == 0b0,
> interrupts are always signalled to the relevant PE, and all masking
> occurs locally, without requiring a DSB SY.
>
> Since commit:
>
> f226650494c6aa87 ("arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear")
>
> ... we handle this dynamically: in most cases a static key is used to
> determine whether to issue a DSB SY, but the entry code must read from
> ICC_CTLR_EL1 as static keys aren't accessible from plain assembly.
>
> It would be much nicer to use an alternative instruction sequence for
> the DSB, as this would avoid the need to read from ICC_CTLR_EL1 in the
> entry code, and for most other code this will result in simpler code
> generation with fewer instructions and fewer branches.
>
> This patch adds a new ARM64_HAS_GIC_PRIO_NO_PMHE cpucap which is only
> set when ICC_CTLR_EL1.PMHE == 0b0 (and GIC priority masking is in use).
> This allows us to replace the existing users of the `gic_pmr_sync`
> static key with alternative sequences which default to a DSB SY and are
> relaxed to a NOP when PMHE is not in use.
I personally find the "negative capability" pretty annoying, specially
considering that hardly anyone uses PMHE. The way the code reads with
this patch, it is always some sort of double negation.
Can't the DSB be patched-in instead, making the PMHE cap a "positive"
one? It shouldn't affect interrupt distribution as long as the
patching occurs before we take interrupts. For modules, the patching
always occurs before we can run the module, so this should be equally
safe.
The patch otherwise looks OK to me.
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
next prev parent reply other threads:[~2023-01-23 13:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-23 12:40 [PATCH 0/4] arm64: pseudo-nmi: elide code when CONFIG_ARM64_PSEUDO_NMI=n Mark Rutland
2023-01-23 12:40 ` [PATCH 1/4] arm64: rename ARM64_HAS_SYSREG_GIC_CPUIF to ARM64_HAS_GIC_SYSREG_CPUIF Mark Rutland
2023-01-23 12:40 ` [PATCH 2/4] arm64: rename ARM64_HAS_IRQ_PRIO_MASKING to ARM64_HAS_GIC_PRIO_MASKING Mark Rutland
2023-01-23 12:40 ` [PATCH 3/4] arm64: add ARM64_HAS_GIC_PRIO_NO_PMHE cpucap Mark Rutland
2023-01-23 13:23 ` Marc Zyngier [this message]
2023-01-23 14:30 ` Mark Rutland
2023-01-24 9:31 ` Marc Zyngier
2023-01-24 12:44 ` Mark Rutland
2023-01-23 12:40 ` [PATCH 4/4] arm64: irqflags: use alternative branches for pseudo-NMI logic Mark Rutland
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=86bkmpmlkc.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).