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

[Peter Xu <peterx@redhat.com>]

On Thu, Nov 13, 2025 at 08:53:30AM +0000, Daniel P. Berrangé wrote:
> On Wed, Nov 12, 2025 at 04:55:42PM -0500, Peter Xu 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>
> > 
> > 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?
> 
> What kernel version are we talking about where there will be
> incompatibility ?  Is it old enough that it pre-dates our
> platform support matrix requirements ?  Ubuntu 22.04 and
> RHEL-9 are currently our targets with the oldest kernels
> that we need to retain compatibility with as the bare min.
> I would expect machine types to work on these old platforms
> without users to having to manually disable default set
> features.

Jason's proposal should have kept the behavior for old machine types so the
strict checks are bypassed, so at least existing running VMs with old
machine types should not be affected on booting.

New machine types may suffer from this indeed, that when running on old
kernels it may needs some tweak on cmdlines.

There's another alternative, which we can introduce an option to allow QEMU
boot but forbidding migration (or at least show a warning to user that
migration may not work properly).  Then everything can be auto-probed like
before, because migration ABI is not necessary.

Personally, I think Jason's proposal is a good trade-off we can consider,
if we think migration should by default supported on any QEMUs that would
boot up properly.

Thanks,

-- 
Peter Xu