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] uapi: adding virtio-gpu capset ID based on unfinalized spec
--

commit ea09d5da0f728b0cac3bb14e59301965633c01f2
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 with ID 8 to
support ROCm compute workloads in virtualized environments. The commit message
notes that the virtio-gpu specification change for this assignment is currently
in progress.

> diff --git a/include/uapi/linux/virtio_gpu.h b/include/uapi/linux/virtio_gpu.h
> index 4f530d90058c7..3d4dfadc9d789 100644
> --- 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 expose VIRTIO_GPU_CAPSET_ROCM to userspace as a stable,
immutable API before the specification is finalized?

The commit message explicitly states that the matching specification change
is only "in progress". Because Linux UAPI is strictly immutable, adding
constants for unfinalized specifications violates standard UAPI merging
practices.

If the OASIS virtio committee assigns ID 8 to a different capability or alters
the capability structure before finalizing the specification, Linux will be
permanently stuck with a UAPI definition that conflicts with the official
virtio specification. This could lead to hypervisor and guest incompatibility.

Should this UAPI addition wait until the specification is officially merged?

>  
>  /* VIRTIO_GPU_CMD_GET_CAPSET_INFO */
>  struct virtio_gpu_get_capset_info {

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