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

> -----Original Message-----
> From: Manish Honap <[email protected]>
> Sent: 13 July 2026 22:15
> To: Alex Williamson <[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]; Manish Honap <[email protected]>
> Subject: 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.

For this patchseries, I think keeping name as VFIO_DEVICE_FLAGS_CXL_TYPE2
is a better choice since Type-2 is the only supported case now; a separate
flag can be added when Type-1/3 support arrives.

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