> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Friday, September 27, 2024 6:57 AM > > On Thu, Sep 26, 2024 at 09:55:28AM -0300, Jason Gunthorpe wrote: > > > I'm not entirely sure yet what this whole 'mgr' component is actually > > doing though. > > Looking more closely I think some of it is certainly appropriate to be > in vfio. Like when something opens the VFIO device it should allocate > the PF device resources from FW, setup kernel structures and so on to > allow the about to be opened VF to work. That is good VFIO topics. IOW > if you don't open any VFIO devices there would be a minimal overhead > > But that stuff shouldn't be shunted into some weird "mgr", it should > just be inside the struct vfio_device subclass inside the variant > driver. yes. That's why I said earlier that the current way looks fine as long as it won't expand to carry vendor specific provisioning interface. The majority of the series is to allocate backend resource when the device is opened. that's perfectly a VFIO topic. Just the point of hardcoding a vGPU type now while stating the mgr will supporting selecting a vGPU type later implies something not clearly designed. > > How to get the provisioning into the kernel prior to VFIO open, and > what kind of control object should exist for the hypervisor side of > the VF, I'm not sure. In mlx5 we used devlink and a netdev/rdma > "respresentor" for alot of this complex control stuff. > the mlx5 approach is what I envisioned. or the fwctl option is also fine after it's merged.
