Re: [PATCH v2 4/4] virtio-net: Add support for USO features
On Fri, Aug 02, 2024 at 12:40:33PM -0400, Michael S. Tsirkin wrote:
On Fri, Aug 02, 2024 at 12:26:22PM -0400, Peter Xu wrote:
> And that's why I was thinking (where I totally agree with you on this) that
> whether we should settle a short term plan first to be on the safe side
> that we start with migration always being compatible, then we figure the
> other approach.
We have two big issues around migration compatibility we never solved:
- some guest visible behaviour depends on a package outside of qemu:
as that package can change, so can qemu behaviour
Any example, or bug link for this one?
- sometimes we change guest visible behaviour and only
discover this after the release: fixing that breaks
migration to one version, not fixing breaks migration to another
In this case it is a bug, IMHO, and not always fixable. It's like QEMU can
crash and coredump, not fixable unless the user upgrades.
Here "upgrades" for migration purpose means, the user should avoid
migration with a broken QEMU version, and one needs to cold reboot into a
new fixed binary rather than a live migration.
The good thing is as long as the user doesn't trigger migration logically
the bug can be avoided.
The bad thing is since it's a migration bug it cannot be fixed by live
migrating to a new QEMU..
AFAICT we did that before, for downstream we fix X.Y.0 with X.Y.1, then
declare X.Y.0 broken, something like that. It's the same for downstream
where we put into similar documentations.
These, to me, look similar enough that I feel we should look
at them together from QAPI POV.
Or maybe I misunderstood here, in that case some elaboration of the QAPI
that mentioned here could help on clarifying things.
So far I don't see any QAPI command can fix a migration bug, for example,
which falls into category 2 above.
Both issues sometimes can have work-arounds, enabling these
would be nice.
Also, both issues have a clean solution, which can come in
two flavors:
1. basic: detecting incompatibility
and not starting qemu on destination (or failing migration,
possibly early, which I consider a less clean solution).
2. advanced: ability to go from a set of configurations to
a flag making them compatible.
--
MST
Thanks,
--
Peter Xu