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

[Peter Xu <peterx@redhat.com>]

On Fri, Nov 14, 2025 at 06:48:42AM +0100, Thomas Huth wrote:
> On 13/11/2025 20.32, Peter Xu wrote:
> > On Thu, Nov 13, 2025 at 12:46:55PM -0500, Michael S. Tsirkin wrote:
> > > failing to start a perfectly good qemu which used to work
> > > because you changed kernels is better than failing to migrate how?
> > > 
> > 
> > I agree this is not pretty.
> > 
> > The very original proposal was having extra features to be OFF by default,
> > only allow explicit selections to enable them when the mgmt / user is aware
> > of the possible hosts to run on top.
> 
> Could it maybe be tied to the "-nodefaults" option of QEMU? If you run QEMU
> with "-nodefaults" (which you should do when planning a migration later),
> these extra features that depend on the kernel version stay OFF. If you run
> QEMU without "-nodefaults", QEMU could enable them if supported by the
> kernel. So that would benefit both, the people running QEMU via management
> layers (using -nodefaults), and the people who just want to quickly launch
> QEMU on the command line. WDYT?

Are the "default set of devices" when without -nodefaults more or less
stable (aka, still live migratable)?  If so, I wonder if there're still
people relying on migrations but using default devices.

The other question is, such proposal also means auto-probe will be OFF for
all serious users.  I am personally OK with such, however it means it'll
also reduce the test coverage that Michael was looking for on new network
features, when QEMU is running on new kernels.

Thanks,

-- 
Peter Xu