Re: [PATCH v8 1/4] drm/virtio-gpu: Add VIRTIO_GPU_CAPSET_ROCM capability

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] virtio-gpu: premature UAPI addition of unassigned capability ID
--

commit 970261f0dfa422eb342665d66f5e54d6944eda73
Author: Honglei Huang <honghuan@amd.com>

drm/virtio-gpu: Add VIRTIO_GPU_CAPSET_ROCM capability

This commit adds a new GPU capability set VIRTIO_GPU_CAPSET_ROCM to support
ROCm compute workloads in virtualized environments. It assigns ID 8 to ROCm,
noting that a matching virtio-gpu specification change is in progress.

> diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
> --- a/include/uapi/linux/virtio_gpu.h
> +++ b/include/uapi/linux/virtio_gpu.h
> @@ -321,6 +321,7 @@ struct virtio_gpu_cmd_submit {
>  #define VIRTIO_GPU_CAPSET_VENUS 4
>  #define VIRTIO_GPU_CAPSET_CROSS_DOMAIN 5
>  #define VIRTIO_GPU_CAPSET_DRM 6
> +#define VIRTIO_GPU_CAPSET_ROCM 8

[Severity: Medium]
Is it safe to add VIRTIO_GPU_CAPSET_ROCM to the Linux UAPI before the virtio
specification has officially assigned it?

Adding an unassigned capability ID to the Linux UAPI creates a risk of a
permanent ABI collision. If the OASIS virtio technical committee assigns ID 8
to a different capability or chooses a different ID for ROCm, the Linux ABI
will conflict with the standard.

Since UAPI changes are immutable once released, could this lock the kernel
into a potentially non-compliant ABI if userspace software compiles against
this UAPI header and uses ID 8 to communicate with the virtio-gpu device?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260918055917.2133574-1-honghuan@amd.com?part=1