Hi Jason In general your idea of moving pure emulation code to user space is a good strategy. On Wed, Apr 29, 2020 at 02:42:20AM -0700, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg@xxxxxxxxxxxx> > > Sent: Monday, April 27, 2020 9:22 PM > > > > On Mon, Apr 27, 2020 at 07:19:39AM -0600, Alex Williamson wrote: > > > > > > It is not trivial masking. It is a 2000 line patch doing comprehensive > > > > emulation. > > > > > > Not sure what you're referring to, I see about 30 lines of code in > > > vdcm_vidxd_cfg_write() that specifically handle writes to the 4 BARs in > > > config space and maybe a couple hundred lines of code in total handling > > > config space emulation. Thanks, > > > > Look around vidxd_do_command() > > > > If I understand this flow properly.. > > > > Hi, Jason, > > I guess the 2000 lines mostly refer to the changes in mdev.c and vdev.c. > We did a break-down among them: > > 1) ~150 LOC for vdev initialization > 2) ~150 LOC for cfg space emulation > 3) ~230 LOC for mmio r/w emulation > 4) ~500 LOC for controlling the work queue (vidxd_do_command), > triggered by write emulation of IDXD_CMD_OFFSET register > 5) the remaining lines are all about vfio-mdev registration/callbacks, > for reporting mmio/irq resource, eventfd, mmap, etc. > > 1/2/3) are pure device emulation, which counts for ~500 LOC. > > 4) needs be in the kernel regardless of which uAPI is used, because it > talks to the physical work queue (enable, disable, drain, abort, reset, etc.) > > Then if just talking about ~500 LOC emulation code left in the kernel, > is it still a big concern to you? 😊 Even when uaccel was under development, one of the options was to use VFIO as the transport, goal was the same i.e to keep the user space have one interface. But the needs of generic user space application is significantly different from exporting a more functional device model to guest, which isn't full emulated device. which is why VFIO didn't make sense for native use. And when we move things from VFIO which is already established as a general device model and accepted by multiple VMM's it gives instant footing without a whole redesign. When we move things from VFIO to uaccel to bolt on the functionality like VFIO, I suspect we would be moving code/functionality from VFIO to Uaccel. I don't know what the net gain would be. IMS is being reworked based on your feedback. And for mdev since the code is minimal for emulation, and rest are control paths that need kernel code to deal with. For mdev, would you agree we can keep the current architecture, and investigate moving some emulation code to user space (say even for standard vfio_pci) and then expand scope later. Cheers Ashok
