On Wed, 25 Jun 2025 08:57:27 +0200 Markus Armbruster via Devel <de...@lists.libvirt.org> wrote:
> [...] > > Back to the design question how to pass configuration via qemu-system to > the passt program with this new backend. > > Your patch replicates passt command line options as optional members of > QAPI type NetDevPasstOptions. Any passt options not covered are > inaccessible. > > Or rather inaccessible via QMP / HMP / CLI. You can still access them > by pointing @passt to a wrapper script. > > This leads us to a possible alternative: make such a wrapper script the > *only* way to configure passt. This is like NetdevTapOptions @script > and @downscript. Mind, I'm not telling you it's a good idea, I'm merely > trying to map the solution space! I'd prefer this idea to having explicit QEMU support (code) for each passt option, mostly because a. it's a lot of code and b. passt doesn't completely guarantee backwards compatibility, only to a reasonable extent (the general idea is to deprecate options first, then to make them disappear in a couple of years). Still, I see three main issues with it: 1. you would still need to distribute an example of a wrapper script, and that will eventually get outdated as well 2. it's complicated and somewhat surprising. You would probably need to configure different wrapper scripts (or functions in scripts?) depending on what guest you're running 3. that would be the usual fun with LSMs. What SELinux label would the script have? Should we define a separate AppArmor policy for it? Or make it a subprofile...? > Instead of trying to make NetDevPasstOptions complete (so you need to > fall back to a wrapper script only when using a version of passt with > different options), we can limit it to a curated set of options. We'd > need to decide which ones :) > > You pointed out yet another alternative: pass through the passt command > line directly. Two obvious ways: a single shell command string to be > passed to system(3), or an array of strings to be passed to execv(3). ...so I'd much prefer this approach (it's actually an alternative I was suggesting to Laurent in some offline chats earlier). We did the same in Podman for pasta(1) (same binary as passt(1), different command, for containers): https://github.com/containers/common/blob/2d2b7a488601a3557301420fce6acb58d0898b95/libnetwork/pasta/pasta_linux.go#L172 where you would do, say: podman --net=pasta:--pcap,/tmp/pasta.pcap,--no-dhcpv6,... This one looks simple, the documentation of options is always updated and maintained as part of passt's documentation, and there's no need to change anything in QEMU if we introduce new options or deprecate some. I would use an array of strings (same as it's done for Podman) rather than a flat argument for system(3), because: > system(3) is a terrible idea with untrusted input, but this is trusted > input. ...even if it's trusted input, a single, long argument with quotes is more error-prone than separate arguments, I think. > Any other interface ideas? > > Since the backend is for human user convenience: which of these ways > would be convenient for human users? As I'm familiar with passt(1) options, passing options through is the most convenient for me, personally. I often use passt without libvirt exactly because it's awkward to pass, say, debugging options (I have to use some horrible /usr/local/bin/passt wrapper script with a switch case inferring the name of the guest from the socket path given as argument, and sometimes it's unpractical): https://issues.redhat.com/browse/RHEL-52281 and it's especially awkward to help users debugging things this way, so it would be nice if QEMU could make it convenient, instead. -- Stefano
