Re: [RFC PATCH] virtio-net: introduce strict peer feature check

[Peter Xu <peterx@redhat.com>]

On Thu, Nov 13, 2025 at 11:47:51AM -0500, Michael S. Tsirkin wrote:
> On Thu, Nov 13, 2025 at 11:37:25AM -0500, Peter Xu wrote:
> > On Thu, Nov 13, 2025 at 11:09:32AM -0500, Michael S. Tsirkin 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 <jasowang@redhat.com>
> > > 
> > > This is not really useful - how do users know how to tweak their
> > > command lines?
> > > We discussed this many times.
> > > To try and solve this you need a tool that will tell you how to start
> > > VM on X to make it migrateable to Y or Z.
> > > 
> > > 
> > > More importantly,
> > > migration is a niche thing and breaking booting perfectly good VMs 
> > > just for that seems wrong.
> > 
> > IMHO Jason's proposal is useful in that it now provides a way to provide
> > ABI stablility but allows auto-ON to exist.
> > 
> > If we think migration is optional, we could add a migration blocker where
> > strict check flag is set to OFF, as I mentioned in the email reply to Dan.
> > As that implies the VM ABI is not guaranteed.
> > 
> > Thanks,
> 
> 
> All you have to do is avoid changing the kernel and ABI is stable.
> Downstreams already do this.

But the whole point of migration is allowing VMs to move between hosts..
hence AFAIU kernel can change.

Downstream will still have problem if some network features will be
optionally supported in some of the RHEL-N branches, because machine types
are defined the same in any RHEL-N, so IIUC it's also possible a VM booting
on a latest RHEL-X.Y qemu/kernel hit issues migrating back to an older
RHEL-X.(Y-1) qemu/kernel if RHEL-X.(Y-1) kernel doesn't have the network
feature available..

It's also not good IMHO to only fix downstream but having upstream face
such problems, even if there's a downstream fix...

This thread was revived only because Jinpu hit similar issues.  IMHO we
should still try to provide a generic solution upstream for everyone.

Thanks,

-- 
Peter Xu