Re: [PATCH v7 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: speculative UAPI capability set ID assignment
--

commit 45781e0bfdae22c4f82ae57badc273b48904b478
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 using ID 8. The commit
message notes that a matching virtio-gpu specification change 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 speculatively assign a UAPI capability set ID while the virtio
specification change is still in progress?

If the virtio technical committee assigns ID 8 to a different capability set
or assigns a different ID to ROCm, the Linux kernel UAPI will permanently
diverge from the official OASIS standard, which could break interoperability
with spec-compliant hypervisors.

Should this UAPI addition wait until the specification assignment is formally
accepted?

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