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

[Alex Williamson <alex@shazbot.org>]

On Thu, 25 Jun 2026 22:24:01 +0530
<mhonap@nvidia.com> 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?

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

> + * @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?

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