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: premature UAPI addition and undocumented ID gap
--

commit 6c8027f028fb5e1fbc1a781cb6e95ed1a88e28f2
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. It assigns ID 8 because ID 7 is used by VIRCL, and
mentions a virtio-gpu specification change is 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 introduce VIRTIO_GPU_CAPSET_ROCM (ID 8) to the immutable Linux
UAPI while the corresponding virtio specification is still in progress?

If the OASIS virtio technical committee rejects the proposal, requests
changes, or assigns a different ID during the review process, the Linux
UAPI will be permanently divergent or broken.

Additionally, should a placeholder macro or documentation be added for the
skipped ID 7? Without it in the header, future developers might assume ID 7
is available and mistakenly reallocate it, creating a potential UAPI
compatibility issue.

>  
>  /* VIRTIO_GPU_CMD_GET_CAPSET_INFO */
>  struct virtio_gpu_get_capset_info {

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