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

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