On 2020/11/1 下午4:26, Paolo Bonzini wrote:
Il sab 31 ott 2020, 22:49 Michael S. Tsirkin <m...@redhat.com
<mailto:m...@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
