RE: [PATCH v3 05/11] vfio: UAPI for CXL Type-2 device passthrough

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?