Feedback on multi-process QEMU muser prototype

Feedback on multi-process QEMU muser prototype

[Stefan Hajnoczi]

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).

3. Drop previous multi-process QEMU commits if they are not needed.

Stefan

Re: Feedback on multi-process QEMU muser prototype

[Felipe Franciosi]

Hi,

> 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.

F.

> 
> 3. Drop previous multi-process QEMU commits if they are not needed.
> 
> Stefan

Re: Feedback on multi-process QEMU muser prototype

[Stefan Hajnoczi]

[-- 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 --]