From: Marc Zyngier <maz@kernel.org>
To: Sascha Bischoff <Sascha.Bischoff@arm.com>
Cc: "kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Joey Gouly <Joey.Gouly@arm.com>,
"yuzenghui@huawei.com" <yuzenghui@huawei.com>,
Suzuki Poulose <Suzuki.Poulose@arm.com>,
"oupton@kernel.org" <oupton@kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>, nd <nd@arm.com>
Subject: Re: [PATCH 09/15] KVM: arm64: vgic-v5: align priority comparison with other GICs
Date: Tue, 31 Mar 2026 18:18:24 +0100 [thread overview]
Message-ID: <867bqr534v.wl-maz@kernel.org> (raw)
In-Reply-To: <729851f0e7d277d308adf04d0008156a01f482bb.camel@arm.com>
On Tue, 31 Mar 2026 16:09:10 +0100,
Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
>
> On Thu, 2026-03-26 at 15:35 +0000, Marc Zyngier wrote:
> > The way the effective priority mask is computed, and then compared
> > to the priority of an interrupt to decide whether to wake-up or not,
> > is slightly odd, and breaks at the limits.
> >
> > This could result in spurious wake-ups that are undesirable.
> >
> > Adopt the GICv[23] logic instead, which checks that the priority
> > value
> > is strictly lower than the mask.
> >
> > Fixes: 933e5288fa971 ("KVM: arm64: gic-v5: Check for pending PPIs")
> > Link:
> > https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/vgic/vgic-v5.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/vgic/vgic-v5.c
> > b/arch/arm64/kvm/vgic/vgic-v5.c
> > index 0f269321ece4b..75372bbfb6a6a 100644
> > --- a/arch/arm64/kvm/vgic/vgic-v5.c
> > +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> > @@ -238,7 +238,7 @@ static u32
> > vgic_v5_get_effective_priority_mask(struct kvm_vcpu *vcpu)
> > */
> > priority_mask = FIELD_GET(FEAT_GCIE_ICH_VMCR_EL2_VPMR,
> > cpu_if->vgic_vmcr);
> >
> > - return min(highest_ap, priority_mask + 1);
> > + return min(highest_ap, priority_mask);
>
> Hi Marc,
>
> This part of your change (dropping the `- 1`) is not correct for GICv5.
> The GICv[23] PMR works differently to the GICv5 PCR.
>
> For GICv[23] the mask is exclusive, i.e., only higher priority (lower
> numerical value) interrupts are of sufficient priority to be signalled.
>
> For GICv5, the priority of an interrupt can be equal to or higher than
> (numerically lower than) the mask. See DMSQKF in the GICv5 spec:
>
> A physical interrupt has Sufficient priority to be signaled when all of
> the following are true:
> * The priority of the interrupt is higher than the physical running
> priority for the Physical Interrupt Domain.
> * The priority of the interrupt is equal to or higher than the
> Physical Priority Mask for the Physical Interrupt Domain.
>
> Therefore, we require this `+ 1` for the priority_mask in order to allow
> us to combine the active priority and priority mask. Else, they operate on
> different scales.
>
> I'd tried to explain this in a comment that lies just outside the diff,
> but hadn't explicitly called out that GICv5 operates differently to
> GICv[23] in this regard. Apologies.
Nothing to apologise about, this is me not being able to read.
>
> > }
> >
> > /*
> > @@ -367,7 +367,7 @@ bool vgic_v5_has_pending_ppi(struct kvm_vcpu
> > *vcpu)
> >
> > scoped_guard(raw_spinlock_irqsave, &irq->irq_lock)
> > has_pending = (irq->enabled &&
> > irq_is_pending(irq) &&
> > - irq->priority <=
> > priority_mask);
> > + irq->priority <
> > priority_mask);
>
> I agree that this was wrong and should never have included the
> equality. This was definitely a bug!
Cool. I'll revert the revert of the first hunk and keep the second
one.
Thanks!
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-03-31 17:18 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 15:35 [PATCH 00/15] KVM: arm64: First batch of vgic-v5 related fixes Marc Zyngier
2026-03-26 15:35 ` [PATCH 01/15] KVM: arm64: vgic: Don't reset cpuif/redist addresses at finalize time Marc Zyngier
2026-03-26 15:35 ` [PATCH 02/15] KVM: arm64: Don't skip per-vcpu NV initialisation Marc Zyngier
2026-03-26 15:35 ` [PATCH 03/15] arm64: Fix field references for ICH_PPI_DVIR[01]_EL2 Marc Zyngier
2026-03-26 15:35 ` [PATCH 04/15] KVM: arm64: Fix writeable mask for ID_AA64PFR2_EL1 Marc Zyngier
2026-03-26 15:35 ` [PATCH 05/15] KVM: arm64: Account for RESx bits in __compute_fgt() Marc Zyngier
2026-03-26 15:35 ` [PATCH 06/15] KVM: arm64: vgic-v5: Hold config_lock while finalizing GICv5 PPIs Marc Zyngier
2026-03-26 15:35 ` [PATCH 07/15] KVM: arm64: vgic-v5: Transfer edge pending state to ICH_PPI_PENDRx_EL2 Marc Zyngier
2026-03-26 15:35 ` [PATCH 08/15] KVM: arm64: vgic-v5: Cast vgic_apr to u32 to avoid undefined behaviours Marc Zyngier
2026-03-26 15:35 ` [PATCH 09/15] KVM: arm64: vgic-v5: align priority comparison with other GICs Marc Zyngier
2026-03-31 15:09 ` Sascha Bischoff
2026-03-31 17:18 ` Marc Zyngier [this message]
2026-04-01 8:18 ` Sascha Bischoff
2026-03-26 15:35 ` [PATCH 10/15] KVM: arm64: vgic-v5: Correctly set dist->ready once initialised Marc Zyngier
2026-03-26 15:35 ` [PATCH 11/15] KVM: arm64: Kill arch_timer_context::direct field Marc Zyngier
2026-03-26 15:35 ` [PATCH 12/15] KVM: arm64: Remove evaluation of timer state in kvm_cpu_has_pending_timer() Marc Zyngier
2026-03-31 15:44 ` Sascha Bischoff
2026-03-31 17:02 ` Marc Zyngier
2026-04-01 8:21 ` Sascha Bischoff
2026-03-26 15:35 ` [PATCH 13/15] KVM: arm64: Move GICv5 timer PPI validation into timer_irqs_are_valid() Marc Zyngier
2026-03-26 15:35 ` [PATCH 14/15] KVM: arm64: Correctly plumb ID_AA64PFR2_EL1 into pkvm idreg handling Marc Zyngier
2026-03-26 15:35 ` [PATCH 15/15] KVM: arm64: Don't advertises GICv3 in ID_PFR1_EL1 if AArch32 isn't supported Marc Zyngier
2026-03-30 17:05 ` [PATCH 00/15] KVM: arm64: First batch of vgic-v5 related fixes Mark Brown
2026-03-31 16:34 ` Sascha Bischoff
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=867bqr534v.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=Joey.Gouly@arm.com \
--cc=Sascha.Bischoff@arm.com \
--cc=Suzuki.Poulose@arm.com \
--cc=broonie@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=nd@arm.com \
--cc=oupton@kernel.org \
--cc=yuzenghui@huawei.com \
/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