Re: Feedback on multi-process QEMU muser prototype

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

On Wed, Jan 15, 2020 at 10:58:38AM +0000, Felipe Franciosi wrote:
> > On Jan 14, 2020, at 3:22 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > 
> > I haven't seen the link to the muser prototype shared on the list yet,
> > so I'm taking the liberty of posting it for discussion:
> > https://github.com/oracle/qemu/tree/multi-process-qemu-v0.4.1-muser
> > 
> > Great that a lot of the multi-process patch series is no longer
> > necessary.  The muser approach requires less code in QEMU.
> > 
> > The following points came to mind:
> > 
> > 1. Configure PCI configuration space, BARs, and MSI/IRQs based on the PCIDevice
> >   instead of hard-coding the LSI SCSI controller's specifics.  That way any
> >   PCIDevice can run as an muser device.
> > 
> > 2. Integrate with QEMU's event loop instead of spawning threads and calling
> >   lm_ctx_run().  The event loop should monitor the muser fd for activity using
> >   aio_set_fd_handler() and then call into libmuser to handle the event.  This
> >   will avoid thread model problems in the future and also allow true
> >   multi-threading (IOThreads).
> 
> Allowing muser to be used like that is in our to-do list.
> 
> (+ Thanos / Swapnil).
> 
> We have to extend muser.ko to allow the device file descriptor to be
> "pollable".  Let me know how soon you want to see that so we can
> prioritise accordingly or assist someone in doing the work.

Last I talked with the multi-process QEMU team the discussion was about
moving forward with the existing QEMU patches and then moving to
VFIO-over-socket.  libmuser makes a nice library API for device emulator
programs and I think it will be revisited when VFIO-over-socket
integration begins.

This makes the pollable fd less of a priority for QEMU at the moment.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]