From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Laurent Vivier" <lvivier@redhat.com>,
qemu-devel@nongnu.org,
"Marc-André Lureau" <marcandre.lureau@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Stefan Weil" <sw@weilnetz.de>,
"Stefano Garzarella" <sgarzare@redhat.com>,
"Jason Wang" <jasowang@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Dr. David Alan Gilbert" <dave@treblig.org>,
"Eric Blake" <eblake@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
devel@lists.libvirt.org
Subject: Re: [PATCH v2 09/10] net: Add passt network backend
Date: Tue, 24 Jun 2025 13:03:28 +0100 [thread overview]
Message-ID: <aFqUENpgRvcYru6L@redhat.com> (raw)
In-Reply-To: <87pleticbb.fsf@pond.sub.org>
On Tue, Jun 24, 2025 at 01:55:20PM +0200, Markus Armbruster wrote:
> Laurent Vivier <lvivier@redhat.com> writes:
>
> > On 24/06/2025 10:16, Markus Armbruster wrote:
> >> Laurent Vivier <lvivier@redhat.com> 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@redhat.com>
> >>
> >> [...]
> >>
> >>> 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 ?
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2025-06-24 12:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-18 15:57 [PATCH v2 00/10] net: Add passt netdev backend Laurent Vivier
2025-06-18 15:57 ` [PATCH v2 01/10] net: Refactor stream logic for reuse in '-net passt' Laurent Vivier
2025-06-18 15:57 ` [PATCH v2 02/10] net: Define net_client_set_link() Laurent Vivier
2025-06-18 15:57 ` [PATCH v2 03/10] net: Introduce helper to identify vhost-user clients Laurent Vivier
2025-07-01 1:36 ` Jason Wang
2025-06-18 15:57 ` [PATCH v2 04/10] net: Add get_vhost_net callback to NetClientInfo Laurent Vivier
2025-06-18 15:57 ` [PATCH v2 05/10] net: Consolidate vhost feature bits into NetClientInfo Laurent Vivier
2025-07-01 1:39 ` Jason Wang
2025-06-18 15:57 ` [PATCH v2 06/10] net: Add get_acked_features callback to NetClientInfo Laurent Vivier
2025-06-18 15:57 ` [PATCH v2 07/10] net: Add save_acked_features " Laurent Vivier
2025-06-18 15:57 ` [PATCH v2 08/10] net: Allow network backends to advertise max TX queue size Laurent Vivier
2025-06-18 15:57 ` [PATCH v2 09/10] net: Add passt network backend Laurent Vivier
2025-06-24 8:16 ` Markus Armbruster
2025-06-24 8:37 ` Laurent Vivier
2025-06-24 11:55 ` Markus Armbruster
2025-06-24 12:03 ` Daniel P. Berrangé [this message]
2025-06-24 12:47 ` Laurent Vivier
2025-06-25 6:57 ` Markus Armbruster
2025-06-30 14:22 ` Stefano Brivio
2025-07-01 1:46 ` Jason Wang
2025-07-01 13:00 ` Laurent Vivier
2025-07-03 10:27 ` Stefano Brivio
2025-06-18 15:57 ` [PATCH v2 10/10] net/passt: Implement vhost-user backend support Laurent Vivier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aFqUENpgRvcYru6L@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=dave@treblig.org \
--cc=devel@lists.libvirt.org \
--cc=eblake@redhat.com \
--cc=jasowang@redhat.com \
--cc=lvivier@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.com \
--cc=sw@weilnetz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).