Re: [PATCH v6 28/49] Documentation: KVM: Extend VGICv5 device attribute docs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] The GICv5 IRS address is now mandatory and SPIs are enabled by default, breaking existing userspace that creates PPI-only VGICv5 instances.
- [Critical] KVM_DEV_ARM_VGIC_GRP_NR_IRQS is redefined for VGICv5 to mean only the number of SPIs, breaking generic VMM logic.
--

commit 09cdbd6c9f58457f6d769b06163f573cb425aea3
Author: Sascha Bischoff <Sascha.Bischoff@arm.com>

Documentation: KVM: Extend VGICv5 device attribute docs

This commit updates the VGICv5 documentation to cover PPI, SPI, and LPI
interrupts, detailing how their pending state is injected. It also documents
the mandatory GICv5 IRS address attribute and its GPA layout requirements.
Finally, it explains the GICv5-specific interpretation of
KVM_DEV_ARM_VGIC_GRP_NR_IRQS, which only counts SPIs instead of the total
number of interrupts.

> diff --git a/Documentation/virt/kvm/devices/arm-vgic-v5.rst b/Documentation/virt/kvm/devices/arm-vgic-v5.rst
> index 70b9162755c7e..c782ea4d4609c 100644
> --- a/Documentation/virt/kvm/devices/arm-vgic-v5.rst
> +++ b/Documentation/virt/kvm/devices/arm-vgic-v5.rst
> @@ -12,12 +12,39 @@ Only one VGIC instance may be instantiated through this API.  The created VGIC

[ ... ]

> +      Setting the address of the IRS in GPA space is mandatory before VGIC
> +      resources are mapped, as the IRS is responsible for handling SPIs and
> +      LPIs. Failure to set the IRS address before the first vCPU run results in
> +      an error.

[Severity: Critical]
Does making the IRS address mandatory introduce a regression for existing
userspace that creates PPI-only VGICv5 instances?

If a VMM creates a VGICv5 without setting KVM_VGIC_V5_ADDR_TYPE_IRS, it looks
like it will now fail to boot:

arch/arm64/kvm/vgic/vgic-init.c:kvm_vgic_map_resources() {
	...
	if (IS_VGIC_ADDR_UNDEF(irs_base)) {
		ret = -ENXIO;
		goto out_slots;
	}
	...
}

It appears it also rejects configuring 0 SPIs, which forces the mandatory
use of the IRS:

arch/arm64/kvm/vgic/vgic-kvm-device.c:vgic_set_common_attr() {
	...
	if (val < VGIC_V5_DEFAULT_NR_SPIS ||
	...
}

Could this cause an ABI regression for legacy VMs that only use PPIs?

> +
> +  KVM_DEV_ARM_VGIC_GRP_NR_IRQS
> +   Attributes:
> +
> +    A value describing the number of SPIs for this GIC instance. This is
> +    GICv5-specific: unlike GICv2/v3, the value does not include SGIs or PPIs.
> +    The value ranges from 32 to KVM's VGICv5 maximum of 1024 SPIs, in
> +    increments of 32. If userspace does not set this attribute, KVM uses 32
> +    SPIs by default.

[Severity: Critical]
Does redefining KVM_DEV_ARM_VGIC_GRP_NR_IRQS to only represent the number of
SPIs introduce a regression for generic VMM logic?

For GICv2/v3, this attribute represents the total number of interrupts
(32 + SPIs). However, for VGICv5, it seems the requested value is assigned
directly to nr_spis without subtracting VGIC_NR_PRIVATE_IRQS:

arch/arm64/kvm/vgic/vgic-kvm-device.c:vgic_set_common_attr() {
	...
	dev->kvm->arch.vgic.nr_spis = val;
	...
}

If a generic VMM passes 32 + N (expecting N SPIs), won't it inadvertently
allocate 32 additional SPIs? Could this inconsistency in the UAPI cause an
ABI regression?

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