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

[Jason Wang]

On 2020/11/1 下午4:26, Paolo Bonzini wrote:
> Il sab 31 ott 2020, 22:49 Michael S. Tsirkin <mst@redhat.com 
> <mailto:mst@redhat.com>> ha scritto:
>
>     > > I still don't get why it must be opaque.
>     >
>     > If the device state format needs to be in the VMM then each device
>     > needs explicit enablement in each VMM (QEMU, cloud-hypervisor, etc).
>
>     And QEMU cares why exactly?
>
>
> QEMU cares for another reason. It is more code to review, and it's 
> worth spending the time to reviewing it only if we can do a decent job 
> at reviewing it.
>
> There are several cases in which drivers migrate non-architectural, 
> implementation-dependent state. There are some examples in nested 
> virtualization (the deadline of the VMX preemption timer) or device 
> emulation (the RTC has quite a few example also of how those changed 
> through the years). We probably don't have anyway the knowledge of the 
> innards of the drivers to do a decent job at reviewing patches that 
> affect those.
>
>     > Let's invert the question: why does the VMM need to understand the
>     > device state of a _passthrough_ device?
>
>     To support cross version migration and compatibility checks.
>
>
> That doesn't have to be in the VMM. We should give guidance but that 
> can be in terms of documentation.


I doubt this can work well if we don't force it via ABI.

Thanks


> Also, in QEMU we chose the path of dropping sections on the source 
> when migrating to older versions, but that can also be considered a 
> deficiency of vmstate---a self-synchronizing format (Anthony many 
> years ago wanted to use X509 as the migration format) would be much 
> better. And for some specific device types we could define standard 
> formats, just like PCI has standard classes.
>
> Paolo
>
>     This problem is harder than it appears, I don't think vendors
>     will do a good job of it without any guidance and standards.
>
>     -- 
>     MST