On Wed, 16 Sep 2026 14:49:36 -0400 Gregory Price <[email protected]> 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
