Re: [PATCH] arm64: errata: Mitigate AmpereOne erratum AC03_CPU_57 and AC04_CPU_29

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] The AmpereOne erratum workaround unconditionally skips deactivating physical interrupts for all nested VMs, causing a physical interrupt state leak.

Pre-existing issues:
- [Critical] The AmpereOne erratum workaround fails to mitigate a Guest-to-Host Denial of Service vector for non-nested (L1) guests.
- [High] Dropping `irq->irq_lock` between computing the LR snapshot and folding it creates a race condition that loses concurrent virtual interrupts.
--

--- Patch [1]: [PATCH] arm64: errata: Mitigate AmpereOne erratum AC03_CPU_57 and AC04_CPU_29 ---
commit d1d195cfc998f3f14be1b81eaa8484fcb7eb08f8
Author: D Scott Phillips <scott@os.amperecomputing.com>

arm64: errata: Mitigate AmpereOne erratum AC03_CPU_57 and AC04_CPU_29

This commit introduces a workaround for an AmpereOne CPU erratum where
deactivating a non-active physical interrupt that is the highest priority
pending interrupt hangs the CPU. The mitigation avoids physical deactivations
when KVM handles a nested VM context.

Link: https://lore.kernel.org/linux-arm-kernel/87ecjybz30.wl-maz@kernel.org/
Link: https://amperecomputing.com/products/developer-errata

[ ... ]

> diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
> index 9e841e7afd4a7..8f1d10872360c 100644
> --- a/arch/arm64/kvm/vgic/vgic-v3.c
> +++ b/arch/arm64/kvm/vgic/vgic-v3.c
> @@ -275,7 +275,9 @@ void vgic_v3_deactivate(struct kvm_vcpu *vcpu, u64 val)
>  		lr = vgic_v3_compute_lr(vcpu, irq) & ~ICH_LR_ACTIVE_BIT;
>  	}
>  
> -	if (lr & ICH_LR_HW)
> +	if ((lr & ICH_LR_HW) &&
> +	    !(cpus_have_final_cap(ARM64_WORKAROUND_AMPERE_AC03_CPU_57) &&
> +	      vgic_state_is_nested(vcpu)))

[Severity: Critical]
This is a pre-existing issue, but does the system remain vulnerable to the
erratum for L1 guests?

Because vgic_state_is_nested(vcpu) evaluates to false for an L1 guest, KVM
bypasses the workaround and still calls vgic_v3_deactivate_phys(). If an
unprivileged guest operating in GICv2 mode on a GICv3 host writes the INTID of
a hardware-backed interrupt to the GICC_DIR MMIO register while it is inactive,
can this directly trigger the host CPU hang?

[Severity: High]
Does unconditionally bypassing the physical deactivation for nested VMs cause
a physical interrupt state leak?

When an L2 guest legitimately deactivates an active hardware-backed
interrupt and it traps to KVM, vgic_v3_deactivate() is called. Since
vgic_state_is_nested(vcpu) evaluates to true, it successfully updates the
virtual state via vgic_v3_fold_lr() but unconditionally skips calling
vgic_v3_deactivate_phys().

Could this leave hardware-backed interrupts, such as the physical timer,
permanently active in the physical GIC distributor and block future timer
interrupts?

>  		vgic_v3_deactivate_phys(FIELD_GET(ICH_LR_PHYS_ID_MASK, lr));
>  
>  	vgic_v3_fold_lr(vcpu, lr);

[Severity: High]
This isn't a bug introduced by this patch, but does dropping irq->irq_lock
between computing the LR snapshot and folding it create a race condition that
loses concurrent virtual interrupts?

vgic_v3_deactivate() takes the lock, computes the snapshot, and then the
scoped_guard ends:

scoped_guard(raw_spinlock, &irq->irq_lock) {
    ...
    lr = vgic_v3_compute_lr(vcpu, irq) & ~ICH_LR_ACTIVE_BIT;
}

If a concurrent device injects an interrupt here via vgic_inject_irq() and
sets irq->pending_latch = true, won't the subsequent call to
vgic_v3_fold_lr(vcpu, lr) re-acquire the lock and evaluate the stale snapshot?

vgic_v3_fold_lr() would see !(val & ICH_LR_STATE) is true and execute:

if (irq->config == VGIC_CONFIG_LEVEL && !(val & ICH_LR_STATE))
    irq->pending_latch = false;

Could this wipe out the newly arrived interrupt and cause guest devices to
stall?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710222128.416581-1-scott@os.amperecomputing.com?part=1