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

[Thanos Makatos]

> -----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://github.com/google/minijail)? bubblewrap
>    (https://github.com/containers/bubblewrap)? 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.

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.