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

[Paolo Bonzini <pbonzini@redhat.com>]

On 29/10/20 16:46, Alex Williamson wrote:
>>> 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.
>
> Yikes, I thought out-of-process devices was exactly the compromise
> being developed to avoid QEMU supporting proprietary modules and ad-hoc
> vendor specific uAPIs.  I think you're actually questioning even the
> premise of developing a standardized API for out-of-process devices
> here.

Strongly agreed!  Some (including me :)) would very much prefer not
having proprietary device emulation at all; at the same time
out-of-process devices make sense for _technical_ reasons (cross-VM
operation, privilege separation, isolation of less secure code) that are
strong enough to accept the reality of allowing proprietary
out-of-process code.  Especially if people could anyway go for an
inferior solution using VFIO, putting the kernel between QEMU and the
proprietary emulation just to get what they want.

Having to choose between opaque migration blobs and proprietary modules,
I would certainly go for the former.

Paolo