> From: Jason Gunthorpe <jgg@xxxxxxxxxx> > Sent: Friday, September 22, 2023 6:07 PM > > On Thu, Sep 21, 2023 at 01:58:32PM -0600, Alex Williamson wrote: > > > If the heart of this driver is simply pretending to have an I/O BAR > > where I/O accesses into that BAR are translated to accesses in the > > MMIO BAR, why can't this be done in the VMM, ie. QEMU? > > That isn't exactly what it does, the IO bar access is translated into an admin > queue command on the PF and excuted by the PCI function. > > So it would be difficult to do that in qemu without also somehow wiring up > qemu to access the PF's kernel driver's admin queue. > > It would have been nice if it was a trivial 1:1 translation to the MMIO bar, but it > seems that didn't entirely work with existing VMs. So OASIS standardized this > approach. > > The bigger picture is there is also a live migration standard & driver in the > works that will re-use all this admin queue infrastructure anyhow, so the best > course is to keep this in the kernel. Additionally in the future the AQ of the PF will also be used to provision the VFs (virtio OASIS calls them member devices), such framework also resides in the kernel. Such PFs are in use by the kernel driver. +1 for keeping this framework in the kernel. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
