[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 23:09:33 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 2020/10/29 下午10:31, Alex Williamson wrote:
On Thu, 29 Oct 2020 21:02:05 +0800
Jason Wang <jasowang@redhat.com> wrote:

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.
Any time during the previous two years of development might have been a
more appropriate time to express your doubts.

Somehow I did that in this series[1]. But the main issue is still there. Is this legal to have a uAPI that turns out to be opaque to userspace? (VFIO seems to be the first). If it's not,  the only choice is to do that in Qemu.

Note that we're not talking about vDPA devices here, we're talking
about arbitrary devices with arbitrary state.  Some degree of migration
support for assigned devices can be implemented in QEMU, Alex Graf
proved this several years ago with i40evf.  Years later, we don't have
any vendors proposing device specific migration code for QEMU.

Yes but it's not necessarily VFIO as well.

Clearly we're also trying to account for proprietary devices where even
for suspend/resume support, proprietary drivers may be required for
manipulating that internal state.  When we move device emulation
outside of QEMU, whether in kernel or to other userspace processes,
does it still make sense to require code in QEMU to support
interpretation of that device for migration purposes?

Well, we could extend Qemu to support property module (or have we supported that now?). And then it can talk to property drivers via either VFIO or vendor specific uAPI.

  That seems
counter to the actual goal of out-of-process devices and clearly hasn't
work for us so far.  Thanks,



[1] https://lore.kernel.org/kvm/20200914084449.0182e8a9@x1.home/T/#m23b08f92a7269fa9676b91dacb6699a78d4b3949

reply via email to

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