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

On Sat, Aug 03, 2024 at 12:54:51AM +0900, Akihiko Odaki wrote: >>>> I'm not sure if I read it right. Perhaps you meant something more generic >>>> than -platform but similar? >>>> >>>> For example, "-profile [PROFILE]" qemu cmdline, where PROFILE can be either >>>> "perf" or "compat", while by default to "compat"? >>> >>> "perf" would cover 4) and "compat" will cover 1). However neither of them >>> will cover 2) because an enum is not enough to know about all hosts. I >>> presented a design that will cover 2) in: >>> https://lore.kernel.org/r/2da4ebcd-2058-49c3-a4ec-8e60536e5cbb@daynix.com >> >> "-merge-platform" shouldn't be a QEMU parameter, but should be something >> separate. > > Do you mean merging platform dumps should be done with another command? I > think we will want to know the QOM tree is in use when implementing > -merge-platform. For example, you cannot define a "platform" when e.g., you > don't know what netdev backend (e.g., user, vhost-net, vhost-vdpa) is > connected to virtio-net devices. Of course we can include those information > in dumps, but we don't do so for VMState. What I was thinking is the generated platform dump shouldn't care about what is used as backend: it should try to probe whatever is specified in the qemu cmdline, and it's the user's job to make sure the exact same qemu cmdline is used in other hosts to dump this information. IOW, the dump will only contain the information that was based on the qemu cmdline. E.g., if it doesn't include virtio device at all, and if we only support such dump for virtio, it should dump nothing. Then the -merge-platform will expect all dumps to look the same too, merging them with AND on each field.

Said that, I actually am still not clear on how / whether it should work at last. At least my previous concern (1) didn't has a good answer yet, on what we do when profile collisions with qemu cmdlines. So far I actually still think it more straightforward that in migration we handshake on these capabilities if possible. And that's why I was thinking (where I totally agree with you on this) that whether we should settle a short term plan first to be on the safe side that we start with migration always being compatible, then we figure the other approach. That seems easier to me, and it's also a matter of whether we want to do something for 9.1, or leaving that for 9.2 for USO*.