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 <[email protected]> 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/[email protected]?part=1
