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

> -----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
> 
> External email: Use caution opening links or attachments
> 
> 
> 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.

> 
> >       __u32   num_regions;    /* Max region index + 1 */
> >       __u32   num_irqs;       /* Max IRQ index + 1 */
> >       __u32   cap_offset;     /* Offset within info struct of first
> cap */
> > @@ -257,6 +258,36 @@ struct vfio_device_info_cap_pci_atomic_comp {
> >       __u32 reserved;
> >  };
> >
> > +/*
> > + * VFIO_DEVICE_INFO capability for CXL Type-2 passthrough devices.
> > + * Present when VFIO_DEVICE_FLAGS_CXL is set on
> vfio_device_info::flags.
> > + *
> > + * @flags: VFIO_CXL_CAP_HOST_FIRMWARE_COMMITTED indicates the host
> CXL
> > + *   subsystem committed the endpoint HDM decoder.
> > + * @hdm_region_idx: VFIO region index for the HDM memory region
> > + *   (subtype VFIO_REGION_SUBTYPE_CXL).
> > + * @comp_reg_region_idx: VFIO region index for the CXL Component
> > + *   Register shadow (subtype VFIO_REGION_SUBTYPE_CXL_COMP_REGS).
> 
> These regions are self describing via the noted CXL subtypes, what's the
> purpose of double reporting them here?

Agreed; I will try to minimize the noise here.

> 
> > + * @comp_reg_bar: PCI BAR index that contains the CXL component
> > + *   register block.  Get-region-info on this BAR returns a
> > + *   VFIO_REGION_INFO_CAP_SPARSE_MMAP that excludes the CXL block.
> > + * @comp_reg_offset: byte offset of the CXL component register block
> > + *   within @comp_reg_bar.
> > + * @comp_reg_size: byte size of the CXL component register block.
> 
> Why don't we describe all of these via a capability on the relevant
> region info?

okay, I will have v4 to remove hdm_region_idx, comp_reg_region_idx,
comp_reg_bar, comp_reg_offset, and comp_reg_size from
vfio_device_info_cap_cxl. The device-level cap will only have flags.

This will also result in component register details to move to a new
VFIO_REGION_INFO_CAP_CXL_COMP_REGS capability on the comp-reg region
info, carrying comp_reg_bar, comp_reg_offset, and comp_reg_size.

Regions will remain self-describing via VFIO_REGION_SUBTYPE_CXL and
VFIO_REGION_SUBTYPE_CXL_COMP_REGS.

> 
> 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.