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