public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
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 v2 19/36] KVM: arm64: gic-v5: Check for pending PPIs
Date: Wed, 7 Jan 2026 15:00:12 +0000	[thread overview]
Message-ID: <20260107150012.0000336b@huawei.com> (raw)
In-Reply-To: <20251219155222.1383109-20-sascha.bischoff@arm.com>

On Fri, 19 Dec 2025 15:52:42 +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 prioirity is greater than or equal to

priority

> 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>
Hi Sascha,

One thing I notice in here is the use of unsigned long vs u64 is a bit
inconsistent.  When it's a register or something we just read from a register
I'd always use u64.

A few other things inline.
> ---
>  arch/arm64/kvm/vgic/vgic-v5.c | 121 ++++++++++++++++++++++++++++++++++
>  arch/arm64/kvm/vgic/vgic.c    |   5 +-
>  arch/arm64/kvm/vgic/vgic.h    |   1 +
>  3 files changed, 126 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> index cb3dd872d16a6..c7ecc4f40b1e5 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -56,6 +56,31 @@ int vgic_v5_probe(const struct gic_kvm_info *info)
>  	return 0;
>  }
>  
> +static u32 vgic_v5_get_effective_priority_mask(struct kvm_vcpu *vcpu)
> +{
> +	struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5;
> +	u32 highest_ap, priority_mask;
> +
> +	/*
> +	 * Counting the number of trailing zeros gives the current
> +	 * active priority. Explicitly use the 32-bit version here as

Short wrap.  I'll stop commenting on these and assume you'll check throughout
(or ignore throughout if you disagree ;) Everyone should use an email
client with rulers!

> +	 * we have 32 priorities. 0x20 then means that there are no
> +	 * active priorities.
> +	 */
> +	highest_ap = cpu_if->vgic_apr ? __builtin_ctz(cpu_if->vgic_apr) : 32;

If the comment is going to say 0x20 means no active, then use hex in the code
as well. Or just use 32 in the comment.

> +
> +	/*
> +	 * An interrupt is of sufficient priority if it is equal to or
> +	 * greater than the priority mask. Add 1 to the priority mask
> +	 * (i.e., lower priority) to match the APR logic before taking
> +	 * the min. This gives us the lowest priority that is masked.
> +	 */
> +	priority_mask = FIELD_GET(FEAT_GCIE_ICH_VMCR_EL2_VPMR, cpu_if->vgic_vmcr);
> +	priority_mask = min(highest_ap, priority_mask + 1);
> +
> +	return priority_mask;

Unless you are going to do more with that in later patches
	return min(highest_ap, priority_mask + 1);
Doesn't lose any significant readability to my eyes.

> +}
> +
>  static bool vgic_v5_ppi_set_pending_state(struct kvm_vcpu *vcpu,
>  					  struct vgic_irq *irq)
>  {
> @@ -131,6 +156,102 @@ void vgic_v5_set_ppi_ops(struct vgic_irq *irq)
>  	}
>  }
>  
> +
> +/*
> + * Sync back the PPI priorities to the vgic_irq shadow state
> + */
> +static void vgic_v5_sync_ppi_priorities(struct kvm_vcpu *vcpu)
> +{
> +	struct vgic_v5_cpu_if *cpu_if = &vcpu->arch.vgic_cpu.vgic_v5;
> +	int i, reg;
> +
> +	/* We have 16 PPI Priority regs */
> +	for (reg = 0; reg < 16; reg++) {

I'd drag the declaration in as
	for (int ret = 0;

> +		const unsigned long priorityr = cpu_if->vgic_ppi_priorityr[reg];
> +
> +		for (i = 0; i < 8; ++i) {
similar for int i = 0 here

Kernel style is getting more accepting of these 'modern' style things ;)
Up to you though if you prefer old school.

> +			struct vgic_irq *irq;
> +			u32 intid;
> +			u8 priority;
> +
> +			priority = (priorityr >> (i * 8)) & 0x1f;

GENMASK(4, 0); maybe.  It's short enough (I can count to 1 f easily enough!)
that I don't really mind which style you use for this.

> +
> +			intid = FIELD_PREP(GICV5_HWIRQ_TYPE, GICV5_HWIRQ_TYPE_PPI);
> +			intid |= FIELD_PREP(GICV5_HWIRQ_ID, reg * 8 + i);
> +
> +			irq = vgic_get_vcpu_irq(vcpu, intid);
> +
> +			scoped_guard(raw_spinlock, &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;
> +	int i, reg;
> +	unsigned int priority_mask;
> +
> +	/* If no pending bits are set, exit early */
> +	if (likely(!cpu_if->vgic_ppi_pendr[0] && !cpu_if->vgic_ppi_pendr[1]))

That likely seems a little bit dubious. I'd be tempted to not mark this
unless you have stats on running systems where the predictors get it wrong
enough that the mark is useful.

> +		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;
> +
> +	/* The shadow priority is only updated on demand, sync it across first */
> +	vgic_v5_sync_ppi_priorities(vcpu);
> +
> +	for (reg = 0; reg < 2; reg++) {
> +		unsigned long possible_bits;
> +		const unsigned long enabler = cpu_if->vgic_ich_ppi_enabler_exit[reg];
Given storage of vgic_ich_ppi_enabler_exit[reg] is a u64 and you are going to
use that length explicitly (the 64 in the bitmap walk below) I'd make these
u64s.  I've not really been keeping an eye open for this in other patches, so
maybe look for other cases where an explicit length is clearer.
u64 shorter as well!

> +		const unsigned long pendr = cpu_if->vgic_ppi_pendr_exit[reg];
> +		bool has_pending = false;
> +
> +		/* 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 > 0x1f)

I 'think' priority_mask > 0x1f is always 0x20?  I'd match that explicitly so the
relationship to the magic value comment above is obvious

> +			return true;
> +
> +		for_each_set_bit(i, &possible_bits, 64) {
> +			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, &irq->irq_lock) {
> +				/*
> +				 * We know that the interrupt is
> +				 * 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;
> +}
> +
>  /*
>   * Detect any PPIs state changes, and propagate the state with KVM's
>   * shadow structures.
> diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
> index cb5d43b34462b..dfec6ed7936ed 100644
> --- a/arch/arm64/kvm/vgic/vgic.c
> +++ b/arch/arm64/kvm/vgic/vgic.c
> @@ -1180,9 +1180,12 @@ int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu)
>  	unsigned long flags;
>  	struct vgic_vmcr vmcr;
>  
> -	if (!vcpu->kvm->arch.vgic.enabled)
> +	if (!vcpu->kvm->arch.vgic.enabled && !vgic_is_v5(vcpu->kvm))
>  		return false;
>  
> +	if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V5)
> +		return vgic_v5_has_pending_ppi(vcpu);
> +
>  	if (vcpu->arch.vgic_cpu.vgic_v3.its_vpe.pending_last)
>  		return true;
>  
> diff --git a/arch/arm64/kvm/vgic/vgic.h b/arch/arm64/kvm/vgic/vgic.h
> index 978d7f8426361..65c031da83e78 100644
> --- a/arch/arm64/kvm/vgic/vgic.h
> +++ b/arch/arm64/kvm/vgic/vgic.h
> @@ -388,6 +388,7 @@ int vgic_v5_probe(const struct gic_kvm_info *info);
>  void vgic_v5_get_implemented_ppis(void);
>  void vgic_v5_set_ppi_ops(struct vgic_irq *irq);
>  int vgic_v5_set_ppi_dvi(struct kvm_vcpu *vcpu, u32 irq, bool dvi);
> +bool vgic_v5_has_pending_ppi(struct kvm_vcpu *vcpu);
>  void vgic_v5_flush_ppi_state(struct kvm_vcpu *vcpu);
>  void vgic_v5_fold_ppi_state(struct kvm_vcpu *vcpu);
>  void vgic_v5_load(struct kvm_vcpu *vcpu);


  reply	other threads:[~2026-01-07 15:00 UTC|newest]

Thread overview: 101+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-19 15:52 [PATCH v2 00/36] KVM: arm64: Introduce vGIC-v5 with PPI support Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 02/36] KVM: arm64: gic-v3: Switch vGIC-v3 to use generated ICH_VMCR_EL2 Sascha Bischoff
2026-01-06 18:00   ` Jonathan Cameron
2026-01-07 10:55     ` Sascha Bischoff
2026-01-09 16:57       ` Sascha Bischoff
2026-01-12 12:41         ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 03/36] arm64/sysreg: Drop ICH_HFGRTR_EL2.ICC_HAPR_EL1 and make RES1 Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 01/36] KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co Sascha Bischoff
2026-01-06 17:23   ` Jonathan Cameron
2026-01-08 16:52     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 06/36] KVM: arm64: gic-v5: Add ARM_VGIC_V5 device to KVM headers Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 05/36] arm64/sysreg: Add GICR CDNMIA encoding Sascha Bischoff
2026-01-06 18:08   ` Jonathan Cameron
2026-01-07  8:39     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 04/36] arm64/sysreg: Add remaining GICv5 ICC_ & ICH_ sysregs for KVM support Sascha Bischoff
2026-01-06 18:28   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 07/36] KVM: arm64: gic: Introduce interrupt type helpers Sascha Bischoff
2026-01-06 14:51   ` Joey Gouly
2026-01-06 18:43   ` Jonathan Cameron
2026-01-08  9:33     ` Sascha Bischoff
2026-01-08 10:25       ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 09/36] KVM: arm64: gic-v5: Detect implemented PPIs on boot Sascha Bischoff
2026-01-06 18:34   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 08/36] KVM: arm64: Introduce kvm_call_hyp_nvhe_res() Sascha Bischoff
2026-01-07 10:30   ` Jonathan Cameron
2026-01-08  9:48     ` Sascha Bischoff
2026-01-08 10:26       ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 11/36] KVM: arm64: gic-v5: Support GICv5 FGTs & FGUs Sascha Bischoff
2026-01-07 11:19   ` Jonathan Cameron
2026-01-08 10:36     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 10/36] KVM: arm64: gic-v5: Sanitize ID_AA64PFR2_EL1.GCIE Sascha Bischoff
2026-01-07 10:58   ` Jonathan Cameron
2026-01-08  9:54     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 12/36] KVM: arm64: gic-v5: Add emulation for ICC_IAFFIDR_EL1 accesses Sascha Bischoff
2026-01-07 11:10   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 14/36] KVM: arm64: gic-v5: Add vgic-v5 save/restore hyp interface Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 13/36] KVM: arm64: gic: Set vgic_model before initing private IRQs Sascha Bischoff
2026-01-07 11:24   ` Jonathan Cameron
2026-01-08 13:39     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 16/36] KVM: arm64: gic-v5: Implement direct injection of PPIs Sascha Bischoff
2026-01-07 12:16   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 17/36] KVM: arm64: gic: Introduce irq_queue and set_pending_state to irq_ops Sascha Bischoff
2026-01-07 12:22   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 15/36] KVM: arm64: gic-v5: Implement GICv5 load/put and save/restore Sascha Bischoff
2026-01-07 12:28   ` Jonathan Cameron
2026-01-08 13:40     ` Sascha Bischoff
2026-01-08 16:52       ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 20/36] KVM: arm64: gic-v5: Init Private IRQs (PPIs) for GICv5 Sascha Bischoff
2026-01-07 15:04   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 18/36] KVM: arm64: gic-v5: Implement PPI interrupt injection Sascha Bischoff
2026-01-06 16:06   ` Joey Gouly
2026-01-06 18:04     ` Sascha Bischoff
2026-01-07 12:50   ` Jonathan Cameron
2026-01-08 14:43     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 19/36] KVM: arm64: gic-v5: Check for pending PPIs Sascha Bischoff
2026-01-07 15:00   ` Jonathan Cameron [this message]
2026-01-08 16:23     ` Sascha Bischoff
2026-01-08 16:57       ` Jonathan Cameron
2026-01-08 16:10   ` Joey Gouly
2026-01-08 16:21     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 22/36] KVM: arm64: gic-v5: Trap and mask guest PPI register accesses Sascha Bischoff
2026-01-07 15:17   ` Jonathan Cameron
2026-01-09 16:59     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 21/36] KVM: arm64: gic-v5: Finalize GICv5 PPIs and generate mask Sascha Bischoff
2026-01-07 15:08   ` Jonathan Cameron
2026-01-08 16:51     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 23/36] KVM: arm64: gic-v5: Support GICv5 interrupts with KVM_IRQ_LINE Sascha Bischoff
2026-01-07 15:29   ` Jonathan Cameron
2026-01-08 16:53     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 24/36] KVM: arm64: gic-v5: Create, init vgic_v5 Sascha Bischoff
2026-01-07 15:49   ` Jonathan Cameron
2026-01-08 16:55     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 25/36] KVM: arm64: gic-v5: Reset vcpu state Sascha Bischoff
2026-01-07 15:51   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 28/36] KVM: arm64: gic: Hide GICv5 for protected guests Sascha Bischoff
2026-01-07 16:12   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 27/36] KVM: arm64: gic-v5: Mandate architected PPI for PMU emulation on GICv5 Sascha Bischoff
2026-01-06 15:06   ` Joey Gouly
2026-01-07  9:48     ` Sascha Bischoff
2026-01-07 16:11   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 26/36] KVM: arm64: gic-v5: Bump arch timer for GICv5 Sascha Bischoff
2026-01-07 16:08   ` Jonathan Cameron
2026-01-09 16:56     ` Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 31/36] KVM: arm64: gic-v5: Set ICH_VCTLR_EL2.En on boot Sascha Bischoff
2025-12-19 15:52 ` [PATCH v2 30/36] KVM: arm64: gic-v5: Introduce kvm_arm_vgic_v5_ops and register them Sascha Bischoff
2026-01-07 16:19   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 29/36] KVM: arm64: gic-v5: Hide FEAT_GCIE from NV GICv5 guests Sascha Bischoff
2026-01-07 16:13   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 34/36] Documentation: KVM: Introduce documentation for VGICv5 Sascha Bischoff
2026-01-07 16:27   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 33/36] KVM: arm64: gic-v5: Probe for GICv5 device Sascha Bischoff
2026-01-07 16:25   ` Jonathan Cameron
2026-01-09 15:00   ` Joey Gouly
2025-12-19 15:52 ` [PATCH v2 32/36] irqchip/gic-v5: Check if impl is virt capable Sascha Bischoff
2026-01-07 16:21   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 35/36] KVM: arm64: selftests: Introduce a minimal GICv5 PPI selftest Sascha Bischoff
2026-01-07 16:38   ` Jonathan Cameron
2025-12-19 15:52 ` [PATCH v2 36/36] KVM: arm64: gic-v5: Communicate userspace-drivable PPIs via a UAPI Sascha Bischoff
2026-01-07 16:51   ` Jonathan Cameron
2026-01-09 17:00     ` Sascha Bischoff
2025-12-19 16:17 ` [PATCH v2 00/36] KVM: arm64: Introduce vGIC-v5 with PPI support 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=20260107150012.0000336b@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox