Re: [PATCH v5 29/49] KVM: arm64: gic-v5: Add GICv5 SPI injection to irqfd

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] GICv5 SPI injection via irqfd breaks KVM_IRQFD_FLAG_RESAMPLE because KVM never observes the guest's EOI.
--

--- Patch [29]: [PATCH v5 29/49] KVM: arm64: gic-v5: Add GICv5 SPI injection to irqfd ---
commit a0b6c4d036693f8696b21a848670f40de7bc34b7
Author: Sascha Bischoff <[email protected]>

KVM: arm64: gic-v5: Add GICv5 SPI injection to irqfd

This commit updates vgic_irqfd_set_irq() to translate irqchip pins into
GICv5 SPI IntIDs before injection. It also validates the IRQCHIP route pins
against the GIC model, supporting up to 1024 SPI pins when using GICv5.

> diff --git a/arch/arm64/kvm/vgic/vgic-irqfd.c b/arch/arm64/kvm/vgic/vgic-irqfd.c
> index 19a1094536e6a..ee1a1b214f03c 100644
> --- a/arch/arm64/kvm/vgic/vgic-irqfd.c
> +++ b/arch/arm64/kvm/vgic/vgic-irqfd.c
> @@ -19,9 +19,14 @@ static int vgic_irqfd_set_irq(struct kvm_kernel_irq_routing_entry *e,
>  			struct kvm *kvm, int irq_source_id,
>  			int level, bool line_status)
>  {
> -	unsigned int spi_id = e->irqchip.pin + VGIC_NR_PRIVATE_IRQS;
> +	unsigned int spi_id;
>  	int ret;
>  
> +	if (kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V5)
> +		spi_id = vgic_v5_make_spi(e->irqchip.pin);

[Severity: High]
Does enabling irqfd injection for GICv5 SPIs here break the
KVM_IRQFD_FLAG_RESAMPLE contract?

If userspace configures an irqfd with KVM_IRQFD_FLAG_RESAMPLE for a
GICv5 SPI, KVM injects the interrupt into the hardware Virtual Domain,
and the guest's EOI is handled directly by the GICv5 hardware.

Since KVM does not track the in-flight state of GICv5 SPIs via List
Registers, does the EOI fail to trap to the hypervisor?

Without KVM observing the guest's EOI, it seems KVM will never call
kvm_notify_acked_irq() and the resampler eventfd will never be signaled.

Could this cause passthrough devices using level-triggered interrupts mapped
to GICv5 SPIs to silently hang after the first interrupt because the
physical interrupt is never unmasked?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=29