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