On Thu, Nov 13, 2025 at 08:31:14AM +0800, Jason Wang wrote: > On Thu, Nov 13, 2025 at 5:55 AM Peter Xu <[email protected]> wrote: > > > > On Fri, Nov 07, 2025 at 10:01:49AM +0800, Jason Wang wrote: > > > We used to clear features silently in virtio_net_get_features() even > > > if it is required. This complicates the live migration compatibility > > > as the management layer may think the feature is enabled but in fact > > > not. > > > > > > Let's add a strict feature check to make sure if there's a mismatch > > > between the required feature and peer, fail the get_features() > > > immediately instead of waiting until the migration to fail. This > > > offload the migration compatibility completely to the management > > > layer. > > > > > > Signed-off-by: Jason Wang <[email protected]> > > > > Jason, thanks for help looking into the problem! > > > > Am I right that after this patch applied, whenever a new QEMU boots with > > the new machine types (e.g. having USO* by default ON), will fail to boot > > on an old kernel that doesn't support USO*, but ask the users to turn off > > USO* features explicitly in the virtio-net devices? > > > > Thanks, > > Yes, I wonder if this can help in dealing with migration compatibility issues.
Yes I think so. The only thing I do not know well is how much risk new qemu will start to fail boot on old kernels. One thing we can do here is be less aggressive on set default-ON to new network features. E.g. for features like USO* we can avoid turning it ON by default when introduced, but wait for a few more releases. Distros / Downstreams can still be aggresive though to tweak the default if they know exactly the kernels to be run on top will be new enough. Thanks again for the proposal, Jason. Anyway, from migration side, feel free to take: Acked-by: Peter Xu <[email protected]> -- Peter Xu
