On Tue, Oct 20, 2026 at 11:41:57AM +0100, Ryan Roberts wrote: > On 16/10/2026 15:42, Jason Gunthorpe wrote: > > On Fri, Oct 16, 2026 at 03:22:00PM +0100, Jean-Philippe Brucker wrote: > >> On Thu, 15 Oct 2026 at 17:41, Jason Gunthorpe <[email protected]> wrote: > >>> I think I said this last time, please don't use vfio mdev for > >>> anything. There is nothing mediated about this. > >> > >> We don't multiplex a device between guests, but the host driver must > >> control part of the device registers while the remainder is assigned to > >> a guest. The host configures accelerator access, stage-2 translation, > >> handles CPUHP and context save/restore. So we can't bind the device to > >> vfio-platform. > > > > That's fine, you can make a proper vfio-cla driver. > > Hi Jason, > > Thanks for taking a look at this! I've been chewing on this comment and trying > to educate myself deeper on the subject. I have a proposal... > > Currently we create a struct device per CLA device instance. But multiple CLA > device instances cooperate within a domain and the domain is the "unit of > isolation";
Well that's weird and a bit confusing. > we can't have some CLAs from a domain assigned to a VM, while others > from the same domain are used by the host. Therefore it didn't feel like the > correct model to unbind one of these devices from the native driver and rebind > it to a cla-vfio driver. mdev seemed to solve this problem nicely for us. > > But looking into it in more detail, I guess something like this might be a bit > more standard: > > - Split the existing CLA driver into three components: > - cla-core: Hardware discovery, domain configuration, struct device > registration and CPU hotplug > - cla-native driver: Provides the user space accelerator interfaces > - cla-vfio driver: Enables domains to be assigned to virtual machines > - Each domain has a struct device (created by the core) > - An individual CLA is not represented by a struct device > - Either cla-native or cla-vfio can then bind to a domain device > - cla-native exposes a char device per domain, per accelerator class > - cla-vfio > > For VFIO, I guess we could use one VFIO region per CLA, which would allow the > VMM to construct a device tree. But it would need to additionally determine > which CPU each CLA is bound to; perhaps that's a sysfs interface that cla-core > could expose? I don't know alot about your CLA, but this sounds reasonable. There may be uses with containers to have the split exposed like this too. Jason
