Re: [PATCH v4 16/48] KVM: arm64: gic-v5: Request doorbells when VPEs enter WFI

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Stale `db_fired` state causes an infinite loop bypassing WFI sleep, pegging the host CPU to 100%.
- [High] Incorrect GICv5 doorbell priority mask (DBPM) calculation drops preempting interrupts and vNMIs.
--

--- Patch [16]: [PATCH v4 16/48] KVM: arm64: gic-v5: Request doorbells when VPEs enter WFI ---
commit 4c69e1e71f915cfc6ba78559fe449983dee20dd6
Author: Sascha Bischoff <Sascha.Bischoff@arm.com>

KVM: arm64: gic-v5: Request doorbells when VPEs enter WFI

This commit requests a GICv5 VPE doorbell when a vcpu enters WFI, allowing 
KVM to be notified when an SPI or LPI becomes pending. It also calculates 
a doorbell priority mask (DBPM) from the virtual priority state to avoid 
waking the guest for masked interrupts.

> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
[ ... ]
> +		/*
> +		 * Request a doorbell *unless* the priority is 0, indicating
> +		 * that no interrupt can wake the CPU up.
> +		 */
> +		if (priority_mask) {

[Severity: High]
Does skipping the doorbell request when the priority is 0 break vNMI wakeups?

Architectural semantics dictate that vNMIs have superpriority and must wake
a vCPU even when the running priority is 0.

> +			int db_irq = vgic_v5_vpe_db(vcpu);
> +			struct irq_data *d = irq_get_irq_data(db_irq);
> +			const struct cpumask *aff = irq_data_get_effective_affinity_mask(d);
> +			int cpu = smp_processor_id();
> +
> +			dbpm = priority_mask - 1;

[Severity: High]
Does subtracting 1 from the priority mask drop valid preempting interrupts?

The hardware doorbell condition triggers when the pending priority is less
than the threshold. If the highest active priority is 5, the vCPU should
be woken by any interrupt with a priority less than 5, for example, 4.

If the priority mask is 5, this code sets the DBPM to 4. The hardware
condition then becomes priority < 4. An interrupt with priority 4 will
not signal the doorbell, despite having a higher priority than the active
interrupt, causing missed wakeups and guest hangs.

> +			cpu_if->vgic_contextr = FIELD_PREP(ICH_CONTEXTR_EL2_DB, 1) |
> +						FIELD_PREP(ICH_CONTEXTR_EL2_DBPM, dbpm);
[ ... ]
> diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
> --- a/arch/arm64/kvm/vgic/vgic.c
> +++ b/arch/arm64/kvm/vgic/vgic.c
[ ... ]
> @@ -1227,8 +1227,12 @@ int kvm_vgic_vcpu_pending_irq(struct kvm_vcpu *vcpu)
>  	unsigned long flags;
>  	struct vgic_vmcr vmcr;
>  
> -	if (vgic_is_v5(vcpu->kvm))
> +	if (vgic_is_v5(vcpu->kvm)) {
> +		if (READ_ONCE(vcpu->arch.vgic_cpu.vgic_v5.gicv5_vpe.db_fired))
> +			return true;

[Severity: High]
Can a stale db_fired state cause an infinite loop bypassing WFI sleep?

The db_fired flag is cleared only in __vgic_v5_make_non_resident(), which
executes during schedule-out.

If a doorbell fires, db_fired becomes true and the vCPU wakes up to enter
the guest. When the vCPU subsequently re-enters WFI without a schedule-out,
kvm_vcpu_block() evaluates kvm_vgic_vcpu_pending_irq(). Because db_fired
remains true, this instantly returns without sleeping.

This leaves the vCPU in an infinite loop returning from WFI and pegging
the host CPU at 100% until a host timer tick forces preemption.

> +
>  		return vgic_v5_has_pending_ppi(vcpu);
> +	}
>  
>  	if (!vcpu->kvm->arch.vgic.enabled)
>  		return false;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724104819.1296803-1-sascha.bischoff@arm.com?part=16