Re: [PATCH v2 4/4] virtio-net: Add support for USO features

[Daniel P . Berrangé]

On Thu, Aug 01, 2024 at 01:51:00AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 31, 2024 at 08:57:52AM -0400, Peter Xu wrote:
> > Could you elaborate why it would fail if with what I proposed?
> 
> First I think I was wrong I misunderstood what you said.
> To summarise, you said:
> 
> - any new feature depending on another package is off by default
> - starting qemu on destination with feature enabled will fail
>   thus migration is not started
> 
> 
> My comment is that this "started" is from qemu point of view,
> from user's POV starting qemu on destination is just the 1st
> step of migration.
> 
> 
> However I agree, this is better since we do not waste bandwidth,
> and I was wrong to say we do.
> 
> My other comment is that adding features becomes even more work
> than it is now.
> 
> So I suggest a single command that dumps some description of host
> features, to be passed to qemu on destination. qemu then fails to
> start on destination if some of these do not work.
> The advantage is that this also helps things like -cpu host,
> and a bunch of other things like vdpa where we like to pass through
> config from kernel.
> 
> The disadvantage is that it does not exactly *fix* migration,
> it just does not let you start it.

This feels like only half a solution, and not the most helpful half.
It prevents you accidentally migrating to a host that lacks some
features, but doesn't help with starting a VM that has migrate
compatible features in the first place.

>From a user POV, the latter is what's most important. Checking for
incompatible features is just a safety net that you should never
need to hit, if QEMU was configured suitably to start with.

So to ensure a QEMU is started with migration compatible features
will still require teaching libvirt about every single feature
that has a host kernel dependancy, so libvirt (or the app using
libvirt) knows to turn this off. This is alot more work for both
libvirt & the mgmt app, than having QEMU provide the generic
"platforms" concept which is extensible without needing further
work outside QEMU.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|