On Mon, 13 Jul 2026 16:44:53 +0000 Manish Honap <[email protected]> wrote:
> > -----Original Message----- > > From: Alex Williamson <[email protected]> > > Sent: 11 July 2026 03:53 > > On Thu, 25 Jun 2026 22:24:01 +0530 > > <[email protected]> wrote: > > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h > > > index 5de618a3a5ee..3707d53c4de5 100644 > > > --- a/include/uapi/linux/vfio.h > > > +++ b/include/uapi/linux/vfio.h > > > @@ -215,6 +215,7 @@ struct vfio_device_info { > > > #define VFIO_DEVICE_FLAGS_FSL_MC (1 << 6) /* vfio-fsl-mc device */ > > > #define VFIO_DEVICE_FLAGS_CAPS (1 << 7) /* Info supports > > caps */ > > > #define VFIO_DEVICE_FLAGS_CDX (1 << 8) /* vfio-cdx > > device */ > > > +#define VFIO_DEVICE_FLAGS_CXL (1 << 9) /* vfio-cxl > > Type-2 device */ > > > > Would we define a different flag for type-1/3 if we ever found a need to > > expose them through vfio? > > Yes. The current flag is named VFIO_DEVICE_FLAGS_CXL and refers to > Type-2 specifically. If Type-1 or Type-3 support is added later, a > separate flag (or a VFIO_DEVICE_INFO_CAP sub-type field) would > distinguish them. I can rename it VFIO_DEVICE_FLAGS_CXL_TYPE2 now if > that is preferable; please advise. I'd keep the broader flag, CXL, and use the device info capability to zero in on the specific features we're trying to expose that can't be readily obtained through DVSEC or needs a mechanism within the vfio uAPI. Thanks, Alex
