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

[Peter Xu <peterx@redhat.com>]

On Thu, Aug 01, 2024 at 01:51:00AM -0400, Michael S. Tsirkin wrote:
> 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.

Something like that could work indeed.  I'm thinking whether it shouldn't
require a new QMP command; that sounds more work, and we also needs Libvirt
cooperations so QEMU migration will still fail.  I wonder whether we can
integrate it into migration handshake that I referred previously in our
TODO item here:

https://wiki.qemu.org/ToDo/LiveMigration#Migration_handshake

The "device handshake" part (in the previous plan) was that we at least can
verify VMSD fields matching on both sides - VMSDs are defined in both QEMU
binaries, so migration can do that already without device opt-in.

What we can do on top of that (or even, before that) is, maybe, allow
device to opt-in in such handshake besides an "VMSD check", so that there
can be something hooked to the VMSDs or similar structures, so the src
QEMU's device A can talk to dest QEMU's device A making sure everything is
good for migration.

Virtio can handshake on host feature lists and we can fail the whole
handshake there.  Same to -cpu, or vDPA, as long as opt-in hook is provided
on both sides.

The good side of it is it sounds natural to integrate this with a handshake
(when we can have it).  Meanwhile, we restrict everything within the device
scope, so neither QEMU nor migration needs to know what happened exactly.

Would that sound workable and better?

Besides, I also wonder what's our next step for this issue.  Should we fix
this on the safe side, and only set ON by default when we have the
handshake ready (in whatever form, either above, or a new QMP command)?

It's just that the handshake in general may still need some thoughts, so
I'm not sure how fast that can ready, considering our very limited
bandwidth so far.  Maybe that can be done separately, but I remember Dan
used to suggest we do handshake right in one shot, and I tend to agree
that'll be nicer.

Thanks,

-- 
Peter Xu