Laurent Vivier <lvivier(a)redhat.com&gt; writes: > On 24/06/2025 10:16, Markus Armbruster wrote: >> Laurent Vivier <lvivier(a)redhat.com&gt; writes: >> >>> This commit introduces support for passt as a new network backend. >>> passt is an unprivileged, user-mode networking solution that provides >>> connectivity for virtual machines by launching an external helper process. >>> >>> The implementation reuses the generic stream data handling logic. It >>> launches the passt binary using GSubprocess, passing it a file >>> descriptor from a socketpair() for communication. QEMU connects to >>> the other end of the socket pair to establish the network data stream. >>> >>> The PID of the passt daemon is tracked via a temporary file to >>> ensure it is terminated when QEMU exits. >>> >>> Signed-off-by: Laurent Vivier <lvivier(a)redhat.com&gt; >> >> [...] >> >>> diff --git a/qapi/net.json b/qapi/net.json >>> index 97ea1839813b..76d7654414f7 100644 >>> --- a/qapi/net.json >>> +++ b/qapi/net.json >>> @@ -112,6 +112,125 @@ >>> 'data': { >>> 'str': 'str' } } >>> >>> +## >>> +# @NetDevPasstOptions: >>> +# >>> +# Unprivileged user-mode network connectivity using passt >>> +# >>> +# @path: path to passt binary >> >> I'd prefer a more descriptive name. >> >> Elsewhere in this file, we refer to programs like this: >> >> # @script: script to initialize the interface >> # >> # @downscript: script to shut down the interface >> >> passt isn't a script, of course. >> >> I don't know, perhaps >> >> # @passt-filename: the passt program to run. >> >> or even >> >> # @passt: Filename of the passt program to run. >> >>> +# >>> +# @quiet: don't print informational messages >> >> What does the printing? A peek at the code I snipped suggests this flag >> is passed to the passt binary as --quiet. Correct? >> >>> +# >>> +# @debug: be verbose >>> +# >>> +# @trace: extra verbose >> >> Likewise for these two. >> >>> +# >>> +# @vhost-user: enable vhost-user [...] >>> +# @udp-ports: UDP ports to forward >> >> Is there anything in this struct that configures qemu-system-FOO itself, >> i.e. isn't just passed to passt? >> > > Yes, all parameters are just passed to passt. > > Do you think it's better not to add all these parameters to netdev backend but only one > generic containing the passt command line parameters? I'm not sure. Thoughts from libvirt's perspective?

On 24/06/2025 14:03, Daniel P. Berrangé wrote: > On Tue, Jun 24, 2025 at 01:55:20PM +0200, Markus Armbruster wrote: >> Laurent Vivier <lvivier(a)redhat.com&gt; writes: >> >>> On 24/06/2025 10:16, Markus Armbruster wrote: >>>> Laurent Vivier <lvivier(a)redhat.com&gt; writes: >>>> >>>>> This commit introduces support for passt as a new network backend. >>>>> passt is an unprivileged, user-mode networking solution that provides >>>>> connectivity for virtual machines by launching an external helper process. >>>>> >>>>> The implementation reuses the generic stream data handling logic. It >>>>> launches the passt binary using GSubprocess, passing it a file >>>>> descriptor from a socketpair() for communication. QEMU connects to >>>>> the other end of the socket pair to establish the network data stream. >>>>> >>>>> The PID of the passt daemon is tracked via a temporary file to >>>>> ensure it is terminated when QEMU exits. >>>>> >>>>> Signed-off-by: Laurent Vivier <lvivier(a)redhat.com&gt; >>>> >>>> [...] >>>> >>>>> diff --git a/qapi/net.json b/qapi/net.json >>>>> index 97ea1839813b..76d7654414f7 100644 >>>>> --- a/qapi/net.json >>>>> +++ b/qapi/net.json >>>>> @@ -112,6 +112,125 @@ >>>>> 'data': { >>>>> 'str': 'str' } } >>>>> +## >>>>> +# @NetDevPasstOptions: >>>>> +# >>>>> +# Unprivileged user-mode network connectivity using passt >>>>> +# >>>>> +# @path: path to passt binary >>>> >>>> I'd prefer a more descriptive name. >>>> >>>> Elsewhere in this file, we refer to programs like this: >>>> >>>> # @script: script to initialize the interface >>>> # >>>> # @downscript: script to shut down the interface >>>> >>>> passt isn't a script, of course. >>>> >>>> I don't know, perhaps >>>> >>>> # @passt-filename: the passt program to run. >>>> >>>> or even >>>> >>>> # @passt: Filename of the passt program to run. >>>> >>>>> +# >>>>> +# @quiet: don't print informational messages >>>> >>>> What does the printing? A peek at the code I snipped suggests this flag >>>> is passed to the passt binary as --quiet. Correct? >>>> >>>>> +# >>>>> +# @debug: be verbose >>>>> +# >>>>> +# @trace: extra verbose >>>> >>>> Likewise for these two. >>>> >>>>> +# >>>>> +# @vhost-user: enable vhost-user >> >> [...] >> >>>>> +# @udp-ports: UDP ports to forward >>>> >>>> Is there anything in this struct that configures qemu-system-FOO itself, >>>> i.e. isn't just passed to passt? >>>> >>> >>> Yes, all parameters are just passed to passt. >>> >>> Do you think it's better not to add all these parameters to netdev backend but only one >>> generic containing the passt command line parameters? >> >> I'm not sure. >> >> Thoughts from libvirt's perspective? > > We already have passt support in libvirt that leverages the existing > vhost-user netdev backend to connect up QEMU. > > I see this backend requires QEMU to be able to spawn the passt binary > itselfm, which is not something libvirt would allow via our security > confinement of QEMU. So that would rule out our ability to consume > this netdev backend, as currently written > > Is there anything QEMU can do with this passt netdev, that can't be > done via the vhost-user backend ? ie is this merely syntax sugar to > make it easier for humans launching QEMU, or is there some feature > / performance benefit ? The idea is only to allow user to run directly QEMU with passt in the same way it's done with the netdev user. There is no other benefit than the easier interface for humans. For instance, we want to run '-nic passt' as we can run '-nic user'.