Il sab 31 ott 2020, 22:49 Michael S. Tsirkin <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. 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 > >
