From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Sascha Bischoff <Sascha.Bischoff@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>, nd <nd@arm.com>,
"maz@kernel.org" <maz@kernel.org>,
"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
Joey Gouly <Joey.Gouly@arm.com>,
Suzuki Poulose <Suzuki.Poulose@arm.com>,
"yuzenghui@huawei.com" <yuzenghui@huawei.com>,
"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
Timothy Hayes <Timothy.Hayes@arm.com>
Subject: Re: [PATCH v3 21/36] KVM: arm64: gic-v5: Check for pending PPIs
Date: Mon, 12 Jan 2026 16:13:29 +0000 [thread overview]
Message-ID: <20260112161329.000063dc@huawei.com> (raw)
In-Reply-To: <20260109170400.1585048-22-sascha.bischoff@arm.com>
On Fri, 9 Jan 2026 17:04:46 +0000
Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
> This change allows KVM to check for pending PPI interrupts. This has
> two main components:
>
> First of all, the effective priority mask is calculated. This is a
> combination of the priority mask in the VPEs ICC_PCR_EL1.PRIORITY and
> the currently running priority as determined from the VPE's
> ICH_APR_EL1. If an interrupt's priority is greater than or equal to
> the effective priority mask, it can be signalled. Otherwise, it
> cannot.
>
> Secondly, any Enabled and Pending PPIs must be checked against this
> compound priority mask. The reqires the PPI priorities to by synced
> back to the KVM shadow state - this is skipped in general operation as
> it isn't required and is rather expensive. If any Enabled and Pending
> PPIs are of sufficient priority to be signalled, then there are
> pending PPIs. Else, there are not. This ensures that a VPE is not
> woken when it cannot actually process the pending interrupts.
>
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Trivial suggestions below. Assuming you'll tidy up the wrap, the other one
is more of an observation than something I particularly care about.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> ---
> arch/arm64/kvm/vgic/vgic-v5.c | 133 ++++++++++++++++++++++++++++++++++
> arch/arm64/kvm/vgic/vgic.c | 3 +
> arch/arm64/kvm/vgic/vgic.h | 1 +
> 3 files changed, 137 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> index c1899add8f5c3..3e2a01e3008c4 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> static bool vgic_v5_ppi_set_pending_state(struct kvm_vcpu *vcpu,
> struct vgic_irq *irq)
> {
> @@ -216,6 +239,112 @@ void vgic_v5_set_ppi_ops(struct vgic_irq *irq)
> irq->ops = &vgic_v5_ppi_irq_ops;
> }
>
> +/*
> + * Sync back the PPI priorities to the vgic_irq shadow state for any interrupts
> + * exposed to the guest (skipping all others).
> + */
> +static void vgic_v5_sync_ppi_priorities(struct kvm_vcpu *vcpu)
> +{
> + struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5;
> + u64 priorityr;
> +
> + /*
> + * We have 16 PPI Priority regs, but only have a few interrupts that the
> + * guest is allowed to use. Limit our sync of PPI priorities to those
> + * actually exposed to the guest by first iterating over the mask of
> + * exposed PPIs.
> + */
> + for (int mask_reg = 0; mask_reg < 2; mask_reg++) {
> + unsigned long *p;
> + int i;
> +
> + p = (unsigned long *)&vcpu->kvm->arch.vgic.gicv5_vm.vgic_ppi_mask[mask_reg];
Following is minor, but maybe worth some more thought:
Even though it's silly I'd be tempted to avoid that cast via
unsigned long bm_p = 0;
bitmap_from_arr64(&bm_p,
&vcpu->kvm->arch.vgic.gicv5_vm.vgic_ppi_mask[mask_reg],
//consider a local variable for this!
64);
for_each_set_bit(i, bm_p, 64) {
}
which compiler should be able to collapse to a simple u64 assignment.
> +
> + for_each_set_bit(i, p, 64) {
> + struct vgic_irq *irq;
> + int pri_idx, pri_reg;
> + u32 intid;
> + u8 priority;
> +
> + pri_reg = (mask_reg * 64 + i) / 8;
> + pri_idx = (mask_reg * 64 + i) % 8;
> +
> + priorityr = cpu_if->vgic_ppi_priorityr[pri_reg];
> + priority = (priorityr >> (pri_idx * 8)) & GENMASK(4, 0);
> +
> + intid = FIELD_PREP(GICV5_HWIRQ_TYPE, GICV5_HWIRQ_TYPE_PPI);
> + intid |= FIELD_PREP(GICV5_HWIRQ_ID, mask_reg * 64 + i);
> +
> + irq = vgic_get_vcpu_irq(vcpu, intid);
> +
> + scoped_guard(raw_spinlock_irqsave, &irq->irq_lock)
> + irq->priority = priority;
> +
> + vgic_put_irq(vcpu->kvm, irq);
> + }
> + }
> +}
> +
> +bool vgic_v5_has_pending_ppi(struct kvm_vcpu *vcpu)
> +{
> + struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5;
> + unsigned int priority_mask;
> +
> + /* If no pending bits are set, exit early */
> + if (!cpu_if->vgic_ppi_pendr[0] && !cpu_if->vgic_ppi_pendr[1])
> + return false;
> +
> + priority_mask = vgic_v5_get_effective_priority_mask(vcpu);
> +
> + /* If the combined priority mask is 0, nothing can be signalled! */
> + if (!priority_mask)
> + return false;
> +
> + for (int reg = 0; reg < 2; reg++) {
> + const u64 enabler = cpu_if->vgic_ppi_enabler[reg];
> + const u64 pendr = cpu_if->vgic_ppi_pendr[reg];
> + unsigned long possible_bits;
> + int i;
> +
> + /* Check all interrupts that are enabled and pending */
> + possible_bits = enabler & pendr;
> +
> + /*
> + * Optimisation: pending and enabled with no active priorities
> + */
> + if (possible_bits && priority_mask == 32)
> + return true;
> +
> + for_each_set_bit(i, &possible_bits, 64) {
> + bool has_pending = false;
> + struct vgic_irq *irq;
> + u32 intid;
> +
> + intid = FIELD_PREP(GICV5_HWIRQ_TYPE, GICV5_HWIRQ_TYPE_PPI);
> + intid |= FIELD_PREP(GICV5_HWIRQ_ID, reg * 64 + i);
> +
> + irq = vgic_get_vcpu_irq(vcpu, intid);
> +
> + scoped_guard(raw_spinlock_irqsave, &irq->irq_lock) {
> + /*
> + * We know that the interrupt is
short wrap. This could be
/*
* We know that the interrupt is enabled and
* pending, so only check the priority.
> + */
> + * enabled and pending, so only check
> + * the priority.
> + */
> + if (irq->priority <= priority_mask)
> + has_pending = true;
> + }
> +
> + vgic_put_irq(vcpu->kvm, irq);
> +
> + if (has_pending)
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
next prev parent reply other threads:[~2026-01-12 16:13 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 17:04 [PATCH v3 00/36] KVM: arm64: Introduce vGIC-v5 with PPI support Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 01/36] KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 02/36] KVM: arm64: gic-v3: Switch vGIC-v3 to use generated ICH_VMCR_EL2 Sascha Bischoff
2026-01-12 14:00 ` Jonathan Cameron
2026-01-28 17:26 ` Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 03/36] arm64/sysreg: Drop ICH_HFGRTR_EL2.ICC_HAPR_EL1 and make RES1 Sascha Bischoff
2026-01-12 14:03 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 05/36] arm64/sysreg: Add GICR CDNMIA encoding Sascha Bischoff
2026-01-12 14:39 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 04/36] arm64/sysreg: Add remaining GICv5 ICC_ & ICH_ sysregs for KVM support Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 06/36] KVM: arm64: gic: Set vgic_model before initing private IRQs Sascha Bischoff
2026-01-12 14:37 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 07/36] KVM: arm64: gic-v5: Add ARM_VGIC_V5 device to KVM headers Sascha Bischoff
2026-01-12 14:41 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 08/36] KVM: arm64: gic: Introduce interrupt type helpers Sascha Bischoff
2026-01-12 14:44 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 09/36] KVM: arm64: gic-v5: Add Arm copyright header Sascha Bischoff
2026-01-12 14:45 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 11/36] KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE Sascha Bischoff
2026-01-12 14:47 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 10/36] KVM: arm64: gic-v5: Detect implemented PPIs on boot Sascha Bischoff
2026-01-12 14:52 ` Jonathan Cameron
2026-01-28 17:28 ` Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 12/36] KVM: arm64: gic-v5: Support GICv5 FGTs & FGUs Sascha Bischoff
2026-01-12 14:55 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 13/36] KVM: arm64: gic-v5: Add emulation for ICC_IAFFIDR_EL1 accesses Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 14/36] KVM: arm64: gic-v5: Add vgic-v5 save/restore hyp interface Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 17/36] KVM: arm64: gic-v5: Finalize GICv5 PPIs and generate mask Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 16/36] KVM: arm64: gic-v5: Implement direct injection of PPIs Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 18/36] KVM: arm64: gic: Introduce queue_irq_unlock and set_pending_state to irq_ops Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 15/36] KVM: arm64: gic-v5: Implement GICv5 load/put and save/restore Sascha Bischoff
2026-01-12 15:49 ` Jonathan Cameron
2026-01-28 17:31 ` Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 19/36] KVM: arm64: gic-v5: Implement PPI interrupt injection Sascha Bischoff
2026-01-12 16:01 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 20/36] KVM: arm64: gic-v5: Init Private IRQs (PPIs) for GICv5 Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 23/36] KVM: arm64: gic-v5: Support GICv5 interrupts with KVM_IRQ_LINE Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 22/36] KVM: arm64: gic-v5: Trap and mask guest ICC_PPI_ENABLERx_EL1 writes Sascha Bischoff
2026-01-12 16:16 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 21/36] KVM: arm64: gic-v5: Check for pending PPIs Sascha Bischoff
2026-01-12 16:13 ` Jonathan Cameron [this message]
2026-01-13 12:16 ` Joey Gouly
2026-01-09 17:04 ` [PATCH v3 25/36] KVM: arm64: gic-v5: Reset vcpu state Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 26/36] KVM: arm64: gic-v5: Bump arch timer for GICv5 Sascha Bischoff
2026-01-12 16:27 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 24/36] KVM: arm64: gic-v5: Create, init vgic_v5 Sascha Bischoff
2026-01-12 16:20 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 27/36] KVM: arm64: gic-v5: Mandate architected PPI for PMU emulation on GICv5 Sascha Bischoff
2026-01-12 16:28 ` Jonathan Cameron
2026-01-13 12:11 ` Joey Gouly
2026-01-09 17:04 ` [PATCH v3 29/36] KVM: arm64: gic-v5: Hide FEAT_GCIE from NV GICv5 guests Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 30/36] KVM: arm64: gic-v5: Introduce kvm_arm_vgic_v5_ops and register them Sascha Bischoff
2026-01-12 16:29 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 28/36] KVM: arm64: gic: Hide GICv5 for protected guests Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 32/36] irqchip/gic-v5: Check if impl is virt capable Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 34/36] Documentation: KVM: Introduce documentation for VGICv5 Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 31/36] KVM: arm64: gic-v5: Set ICH_VCTLR_EL2.En on boot Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 33/36] KVM: arm64: gic-v5: Probe for GICv5 device Sascha Bischoff
2026-01-09 17:04 ` [PATCH v3 36/36] KVM: arm64: gic-v5: Communicate userspace-driveable PPIs via a UAPI Sascha Bischoff
2026-01-12 16:42 ` Jonathan Cameron
2026-01-09 17:04 ` [PATCH v3 35/36] KVM: arm64: selftests: Introduce a minimal GICv5 PPI selftest Sascha Bischoff
2026-01-12 16:38 ` Jonathan Cameron
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=20260112161329.000063dc@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Joey.Gouly@arm.com \
--cc=Sascha.Bischoff@arm.com \
--cc=Suzuki.Poulose@arm.com \
--cc=Timothy.Hayes@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=maz@kernel.org \
--cc=nd@arm.com \
--cc=oliver.upton@linux.dev \
--cc=peter.maydell@linaro.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 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.