Re: [PATCH v4 07/27] vfio/pci: Detect CXL devices and load vfio-cxl on demand

[Jonathan Cameron <jic23@kernel.org>]

On Thu, 13 Aug 2026 15:06:11 +0530
<mhonap@nvidia.com> wrote:

> From: Manish Honap <mhonap@nvidia.com>
> 
> A CXL device needs the vfio-cxl callbacks, but pulling vfio-cxl and the
> CXL core in unconditionally would bloat every vfio-pci setup. At bind,
> detect a CXL device with pcie_is_cxl() and request_module("vfio-cxl")
> only then, and hand the device to the registered ops.
> 
> Each bound CXL device pins vfio-cxl through try_module_get() and drops
> the reference at release, so vfio-cxl can unload once no CXL device is
> bound. If vfio-cxl is absent the device is driven as plain vfio-pci.
> 
> Signed-off-by: Manish Honap <mhonap@nvidia.com>
> ---
>  drivers/vfio/pci/vfio_pci_core.c | 81 ++++++++++++++++++++++++++++++--
>  include/linux/vfio_pci_core.h    |  3 ++
>  2 files changed, 81 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
> index 88e68d43af9a..0f9b5dfeea66 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -2176,6 +2176,44 @@ static void vfio_pci_vga_uninit(struct vfio_pci_core_device *vdev)
>  					      VGA_RSRC_LEGACY_MEM);
>  }
>  
> +static const struct vfio_cxl_ops *vfio_pci_cxl_ops;
> +static DEFINE_MUTEX(vfio_pci_cxl_ops_lock);
> +
> +static const struct vfio_cxl_ops *vfio_pci_get_cxl_ops(void)
> +{
> +	const struct vfio_cxl_ops *ops;
> +
> +	mutex_lock(&vfio_pci_cxl_ops_lock);
> +	ops = vfio_pci_cxl_ops;
> +	if (ops && !try_module_get(ops->owner))
> +		ops = NULL;
> +	mutex_unlock(&vfio_pci_cxl_ops_lock);
> +
> +	return ops;
> +}
> +
> +/*
> + * A CXL Type-2 device advertises both CXL.cache and CXL.mem in its CXL DVSEC.
> + * pcie_is_cxl() is also true for Type-1 (cache only) and Type-3 (mem only)
> + * devices, which the vfio-cxl provider does not handle, so confirm the Type-2
> + * identity before engaging it.

We don't expect to handle type 3 class code compliant devices, but what about
the things referred to sometimes as CXL Type 3+?
No CXL.cache support, but accelerators none the less - typically using back
invalidate to ensure what they are working on isn't held by the host and
CXL.IO (i.e. PCI) for control path.

It is also plausible we'd pass a full compressed RAM device through to the
guest without paravirtualizing like we currently plan to do for class
code Type 3 devices (for DCD, sharing etc). +CC Gregory to point out where
I am wrong on this ;)

Not sure what that means for this checking function.

More generally, why are we controlling usecases?  A class code complaint type 3
device 'could' be passed through I think if someone wanted to do that.
I'd not encourage it but why is it a linux policy to not support it?

Jonathan



> + */
> +static bool vfio_pci_is_cxl_type2(struct pci_dev *pdev)
> +{
> +	u16 dvsec, cap;
> +
> +	dvsec = pci_find_dvsec_capability(pdev, PCI_VENDOR_ID_CXL,
> +					  PCI_DVSEC_CXL_DEVICE);
> +	if (!dvsec)
> +		return false;
> +
> +	if (pci_read_config_word(pdev, dvsec + PCI_DVSEC_CXL_CAP, &cap))
> +		return false;
> +
> +	return (cap & PCI_DVSEC_CXL_CACHE_CAPABLE) &&
> +	       (cap & PCI_DVSEC_CXL_MEM_CAPABLE);
> +}