Manish Honap wrote:
> > -----Original Message-----
> > From: Alex Williamson <[email protected]>
> > Sent: 11 July 2026 03:53
> > To: Manish Honap <[email protected]>
> > Cc: [email protected]; [email protected]; [email protected];
> > [email protected]; Ankit Agrawal <[email protected]>;
> > [email protected]; [email protected];
> > [email protected]; [email protected]; [email protected];
> > [email protected]; Neo Jia <[email protected]>; Krishnakant Jaju
> > <[email protected]>; Vikram Sethi <[email protected]>; Zhi Wang
> > <[email protected]>; [email protected]; [email protected];
> > [email protected]; [email protected]; linux-
> > [email protected]; [email protected]
> > Subject: Re: [PATCH v3 05/11] vfio: UAPI for CXL Type-2 device
> > passthrough
> >
[..]
> >
> > 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.
The CXL specification itself has deprecated the "Type" names because
they are ambiguous. For example, you can have a "Type-3" device that
supports "device memory (HDM-DB)", Type-2 is a superset of Type-1 in
many cases, etc.
This flag will never be able to capture a coherent / standard set of
device capabilities. It can really only be a plain "CXL" flag with
an implementation that is ready for the superset of capabilities:
CXL.cache, HDM-H (host-only memory expansion), HDM-D (legacy device
memory), HDM-DB (device memory via device cache management
back-invalidate).
I think the HDM-{H,D,DB} difference are not relevant to VFIO, it is all
just CXL HDM.
The capabilities that may need a different VFIO implementation model are
interleaved devices and maybe dynamic capacity devices, but that is not
a type designation.
[..]
> > Does that leave this device level capability describing the device as
> > type-2 (by existence), with only a flags field to declare HDM as
> > firmware committed, for future compatibility should we support non-fw
> > committed? Thanks,
> >
> > Alex
>
> Yes, I will shape the v4 in this direction. The device-level CAP_CXL
> shrinks to "this is a CXL device" (by existence) plus a flags field whose
> only defined bit today is HOST_FIRMWARE_COMMITTED, leaving
> room for a future non-fw-committed mode. Everything else moves to region
> caps. Thanks for this suggestion.
How can VFIO discern if the HDM is host firwmare committed? If
devm_cxl_probe_mem() grows to auto-activate unmapped capacity rather
than finds firmware committed decoders, can VFIO even tell the
difference?
