Jason Wang <[email protected]> writes: > Hi Markus, > > On Thu, Dec 4, 2025 at 4:09 PM Markus Armbruster <[email protected]> wrote: >> >> Ben Chaney <[email protected]> writes: >> >> > From: Steve Sistare <[email protected]> >> > >> > Provide the cpr=on option to preserve TAP and vhost descriptors during >> > cpr-transfer, so the management layer does not need to create a new >> > device for the target. >> > >> > Save all tap fd's in canonical order, leveraging the index argument of >> > cpr_save_fd. For the i'th queue, the tap device fd is saved at index 2*i, >> > and the vhostfd (if any) at index 2*i+1. >> > >> > tap and vhost fd's are passed by name to the monitor when a NIC is hot >> > plugged, but the name is not known to qemu after cpr. Allow the manager >> > to pass -1 for the fd "name" in the new qemu args to indicate that QEMU >> > should search for a saved value. Example: >> > >> > -netdev tap,id=hostnet2,fds=-1:-1,vhostfds=-1:-1,cpr=on >> >> Hmm. See below. >> >> > >> > Signed-off-by: Steve Sistare <[email protected]> >> > Signed-off-by: Ben Chaney <[email protected]> >> >> [...] >> >> > diff --git a/qapi/net.json b/qapi/net.json >> > index 118bd34965..264213b5d9 100644 >> > --- a/qapi/net.json >> > +++ b/qapi/net.json >> > @@ -355,6 +355,8 @@ >> ## >> # @NetdevTapOptions: >> # >> # Used to configure a host TAP network interface backend. >> # >> # @ifname: interface name >> # >> # @fd: file descriptor of an already opened tap >> # >> # @fds: multiple file descriptors of already opened multiqueue capable >> # tap >> >> Not this patch's fault: the interface is misguided, and its >> documentation inadequate. >> >> @fds is a string of file descriptor names or numbers separated by ':'. >> Not documented. I found out by reading the code. >> >> This violates QAPI design principle "no string parsing". It should be >> an array of strings. >> > > I agree with your concern. Just a note that this "fds" was introduced > before QAPI if I am not wrong.
It's from 2013 (commit 264986e2c8f). QAPI was still young then (netdev_add had been QAPIfied less than a year ago), we had much to learn, and interface review barely happened. All understandable, and no reason to throw shade on anyone involved :)
