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

[Jonathan Cameron]

On Wed, 16 Sep 2026 14:49:36 -0400
Gregory Price <gourry@xxxxxxxxxx> wrote:

> On Wed, Sep 16, 2026 at 07:16:59PM +0100, Jonathan Cameron wrote:
> > > +/*
> > > + * 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+?  
> 
> Dan has previously (and I think would continue) to just call that
> an accelerator - because it is.
> 
> I think the Type 1/2/3 nomenclature is stale and needs to go away,
> it's outlived its usefulness.
> 
> To your point below, a compressed ram device is really an accelerator
> with CXL.io and CXL.mem.  All the spec says (used to say?) about
> "Type 2" is that it *may* support CXL.cache - it doesn't require it.
> 
> > 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 ;)
> >   
> 
> Plausible, possible, feasible - yes.
> 
> Sane?  More sane than using it as a normal memory device on the host
> assuming RAS signals from the device can't overwhelm the host (unknown).
> 
> > More generally, why are we controlling usecases?  A class code compliant 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?
> >   
> 
> The only scenario I can think of that you'd want to pass a simple
> expander all the way through to the guest would be RAS signals - which
> I think still require host plumbing anyway to avoid passing said signals
> to the wrong guest depending on how you've chopped up the region.
> 
Taking just the compressed case...
If there are capacity signals etc I'm not sure I'd want to have to paravirtualize
those. Plus I really don't fancy making a single compressed device provide memory
into multiple hosts. That's a whole new level of paravirtualization of noisy
neighbours.  Ma! Someone else wrote really uncompressible memory and now there
is none left for me.

> Basically if you need DPA/HPA data from the device to be interpreted by
> the kernel, the guest needs a translation mechanism.

Hmm. That is potentially ugly. But I guess a problem for any accelerator.
If they are firmware first not too bad as it's just normal memory error
reporting so we create a cper in the host with the GPA and send it on
it's merry way.  

> 
> In practice I can see passing a virtualized, locked auto-decoder through
> to the guest with the same HPA/DPA values as the real device so the
> signals can be delivered quickly with limited host interposition.

We'd lie (trap / emulate) the device decoder and probably the topology so that
what you see matches up and device provided DPAs will translate to GPAs.
I forget if that bit is in this patch set or not.

> 
> You would probably need on-device vitualization support to do "proper"
> passthrough so the device can route signals to the guest directly.

Hmm. We may get a way to do that at somepoint but so far it's pretty
simple so I'd argue only a few things need to look different in the
guest to what they do in the host.

> 
> Anyway, you could pass it through, sure, why not.
> 
> We shouldn't limit it, if only because we're not clairvoyant about
> what will be useful tomorrow.

Agreed.

J
> 
> ~Gregory