RE: Out-of-Process Device Emulation session at KVM Forum 2020

[Thanos Makatos]

> -----Original Message-----
> From: Qemu-devel <qemu-devel-
> bounces+thanos.makatos=nutanix.com@nongnu.org> On Behalf Of Thanos
> Makatos
> Sent: 28 October 2020 09:32
> To: Stefan Hajnoczi <stefanha@redhat.com>; qemu-devel@nongnu.org
> Cc: Elena Ufimtseva <elena.ufimtseva@oracle.com>;
> john.g.johnson@oracle.com; mst@redhat.com <mtsirkin@redhat.com>;
> jag.raman@oracle.com; slp@redhat.com; kraxel@redhat.com; Felipe
> Franciosi <felipe@nutanix.com>; Marc-André Lureau
> <marcandre.lureau@redhat.com>; Alex Bennée <alex.bennee@linaro.org>;
> David Gibson <david@gibson.dropbear.id.au>
> Subject: RE: Out-of-Process Device Emulation session at KVM Forum 2020
> 
> > -----Original Message-----
> > From: Stefan Hajnoczi <stefanha@redhat.com>
> > Sent: 27 October 2020 15:14
> > To: qemu-devel@nongnu.org
> > Cc: Alex Bennée <alex.bennee@linaro.org>; mst@redhat.com
> > <mtsirkin@redhat.com>; john.g.johnson@oracle.com; Elena Ufimtseva
> > <elena.ufimtseva@oracle.com>; kraxel@redhat.com;
> > jag.raman@oracle.com; Thanos Makatos <thanos.makatos@nutanix.com>;
> > Felipe Franciosi <felipe@nutanix.com>; Marc-André Lureau
> > <marcandre.lureau@redhat.com>; slp@redhat.com; David Gibson
> > <david@gibson.dropbear.id.au>
> > Subject: Out-of-Process Device Emulation session at KVM Forum 2020
> >
> > There will be a birds-of-a-feather session at KVM Forum, a chance for
> > us to get together and discuss Out-of-Process Device Emulation.
> >
> > Please send suggestions for the agenda!
> >
> > These sessions are a good opportunity to reach agreement on topics that
> > are hard to discuss via mailing lists.
> >
> > Ideas:
> >  * How will we decide that the protocol is stable? Can third-party
> >    applications like DPDK/SPDK use the protocol in the meantime?
> >  * QEMU build system requirements: how to configure and build device
> >    emulator binaries?
> >  * Common sandboxing solution shared between C and Rust-based
> binaries?
> >    minijail (https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_google_minijail-29-
> 3F&d=DwIFAw&c=s883GpUCOChKOHiocYtGcg&r=XTpYsh5Ps2zJvtw6ogtti46a
> tk736SI4vgsJiUKIyDE&m=hPc4ln1oFnCIYCRna-
> C027BO06__al6zPJhAs0_KcP8&s=dqqLRGO3GvV4gAEqkMXzbhm5TtOHqLGQ
> d_0SBlzubp0&e=  bubblewrap
> >    (https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_containers_bubblewrap-29-
> 3F&d=DwIFAw&c=s883GpUCOChKOHiocYtGcg&r=XTpYsh5Ps2zJvtw6ogtti46a
> tk736SI4vgsJiUKIyDE&m=hPc4ln1oFnCIYCRna-
> C027BO06__al6zPJhAs0_KcP8&s=Rnd-
> 6YVz2xrg0Vrm6ukannwt3kmbQ8L7upVLrEc227g&e=  systemd-run?
> >
> > Stefan
> 
> Here are a couple of issues we'd also like to talk about:
> 
> Fast switching from polling to interrupt-based notifications: when a single
> process is emulating multiple devices then it might be more efficient to poll
> instead of relying on interrupts for notifications. However, during periods
> when
> the guests are mostly idle, polling might unnecessary, so we'd like to be able
> switch to interrupt-based notifications at a low cost.

Correction: there are no interrupts involved here, just guest to device 
notifications.

> 
> Device throttling during live migration: a device can easily dirty huge 
> amounts
> of guest RAM which results in live migration taking too long or making it hard
> to estimate progress. Ideally, we'd like to be able to instruct an out-of-
> process
> device emulator to make sure it won't dirty too many guest pages during a
> specified window of time.