[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jason Wang
Subject: Re: Out-of-Process Device Emulation session at KVM Forum 2020
Date: Thu, 29 Oct 2020 21:02:05 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 2020/10/29 下午8:08, Stefan Hajnoczi wrote:
Here are notes from the session:

protocol stability:
     * vhost-user already exists for existing third-party applications
     * vfio-user is more general but will take more time to develop
     * libvfio-user can be provided to allow device implementations

     * Should QEMU launch device emulation processes?
         * Nicer user experience
         * Technical blockers: forking, hotplug, security is hard once
QEMU has started running
         * Probably requires a new process model with a long-running
QEMU management process proxying QMP requests to the emulator process

     * dbus-vmstate
     * VFIO live migration ioctls
         * Source device can continue if migration fails
         * Opaque blobs are transferred to destination, destination can
fail migration if it decides the blobs are incompatible

I'm not sure this can work:

1) Reading something that is opaque to userspace is probably a hint of bad uAPI design 2) Did qemu even try to migrate opaque blobs before? It's probably a bad design of migration protocol as well.

It looks to me have a migration driver in qemu that can clearly define each byte in the migration stream is a better approach.

         * How does the VMM share the migration data region with the
device emulation process?
             * The vfio-user protocol can trap or mmap
     * device versioning (like versioned machine types) needed to pin
the guest-visible device ABI
     * Felipe will investigate live migration

     * How to support reconnection?
         * QEMU has relatively little state of a vfio-user device
         * vhost-user has more state so it's a little easier to
reconnect or migrate

It could be even more easier, e.g for the inflight indices, we can design (or forcing to use in order) virtqueue carefully then we don't need any auxiliary data structure.


     * Build in reconnection and live migration from the start to avoid
difficulties in the future
     * Relationship between migration and reconnection?
         * VFIO has a mechanism for saving/loading device state
         * Lots of different reconnection cases that need to be thought through

security & sandboxing:
     * Goal: make it easy to lock down the process so developers don't
need to reinvent sandboxing
     * minijail
         * in-process
     * firecracker jailer
     * bubblewrap
         * launcher tool
     * systemd-run
         * launcher tool

reply via email to

[Prev in Thread] Current Thread [Next in Thread]