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