Re: [PATCH 08/60] Documentation: kvm: introduce "VM plane" concept

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The documented API for VM planes directly contradicts the restrictions claimed in the commit message.
- [Medium] Implicit 'last caller wins' global state in KVM_SET_GSI_ROUTING for planes prevents concurrent routing to multiple planes.
- [Low] Missing word 'with' in KVM_CREATE_VCPU plane constraints.
--

commit 1a4c73ae992840db0208f48635c236bd7636131e
Author: Paolo Bonzini <pbonzini@redhat.com>

Documentation: kvm: introduce "VM plane" concept

This commit introduces the concept of "VM planes" to represent virtual
privilege levels (like AMD VMPLs, Intel TDX, and Arm CCA planes). It
documents how these planes and their restricted subset of KVM APIs are
exposed to userspace through separate file descriptors.

> In fact for
> the vm file descriptor it is only three ioctls: KVM_CHECK_EXTENSION,
> KVM_SIGNAL_MSI, KVM_SET_MEMORY_ATTRIBUTES.  For vCPUs it is basically
> KVM_GET/SET_*.

[Severity: Medium]
Does the documentation in api.rst diverge from this commit message?

The commit message states that only three ioctls are supported on the VM
file descriptor for planes other than 0. However, the documentation
changes below mark both KVM_CREATE_VCPU and KVM_SET_GSI_ROUTING as
"vm ioctl (all planes)".

> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 52bbbb553ce10..d90b4a406454c 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
[ ... ]
> @@ -350,6 +367,8 @@ machines, the resulting vcpu fd can be memory mapped at page offset
>  KVM_S390_SIE_PAGE_OFFSET in order to obtain a memory map of the virtual
>  cpu's hardware control block.
>  
> +VCPUs for non-zero planes can only be created if the VCPU the same index has
> +already been created for plane zero.

[Severity: Low]
This isn't a bug, but should "the VCPU the same index has" be "the VCPU
with the same index has"?

[ ... ]
> @@ -1886,11 +1905,14 @@ The flags bitmap is defined as::
>  
>  :Capability: KVM_CAP_IRQ_ROUTING
>  :Architectures: x86 s390 arm64
> -:Type: vm ioctl
> +:Type: vm ioctl (all planes)
>  :Parameters: struct kvm_irq_routing (in)
>  :Returns: 0 on success, -1 on error
>  
>  Sets the GSI routing table entries, overwriting any previously set entries.
> +Note that the kernel maintains only one GSI routing table for all planes. The
> +plane for which the GSI routing table was set last will receive all interrupts
> +signaled through GSI pins.

[Severity: Medium]
Does this implicit "last caller wins" global state prevent concurrent routing
to multiple planes?

Since KVM_SET_GSI_ROUTING replaces the entire routing table at once, it
appears a call on one plane's VM fd will hijack all GSI interrupts for that
plane, overwriting any previous plane's configuration. Is there a way to
concurrently route different GSIs to different planes under this UAPI
design?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608144252.351443-1-joro@8bytes.org?part=8