On Tue, Nov 19, 2019 at 04:33:40PM -0500, Michael S. Tsirkin wrote: > On Tue, Nov 19, 2019 at 03:15:47PM -0400, Jason Gunthorpe wrote: > > On Tue, Nov 19, 2019 at 01:58:42PM -0500, Michael S. Tsirkin wrote: > > > On Tue, Nov 19, 2019 at 12:46:32PM -0400, Jason Gunthorpe wrote: > > > > As always, this is all very hard to tell without actually seeing real > > > > accelerated drivers implement this. > > > > > > > > Your patch series might be a bit premature in this regard. > > > > > > Actually drivers implementing this have been posted, haven't they? > > > See e.g. https://lwn.net/Articles/804379/ > > > > Is that a real driver? It looks like another example quality > > thing. > > > > For instance why do we need any of this if it has '#define > > IFCVF_MDEV_LIMIT 1' ? > > > > Surely for this HW just use vfio over the entire PCI function and be > > done with it? > > What this does is allow using it with unmodified virtio drivers > within guests. You won't get this with passthrough as it only > implements parts of virtio in hardware. I don't mean use vfio to perform passthrough, I mean to use vfio to implement the software parts in userspace while vfio to talk to the hardware. kernel -> vfio -> user space virtio driver -> qemu -> guest Generally we don't want to see things in the kernel that can be done in userspace, and to me, at least for this driver, this looks completely solvable in userspace. Jason
