Re: [PATCH RFE] conf: Add extraArgs option to passt backend

On Wed, Jun 25, 2025 at 09:40:16AM +0200, Enrique Llorente via Devel wrote: > Add support for passing extra arguments to the passt binary through > the domain XML configuration. This allows users to specify additional > command-line arguments for passt that are not covered by existing > structured fields. > > The new extraArgs attribute is added to the backend element: > <backend type='passt' extraArgs='--debug --no-dhcp -v'/> > > The extraArgs string is parsed using g_shell_parse_argv() to split > it into individual arguments before passing them to the passt command. > > This change includes: > - New field in virDomainNetBackend structure > - XML schema update to allow extraArgs attribute > - Parsing and formatting support in domain_conf.c > - Backend comparison function update > - Memory cleanup for the new field > - QEMU passt integration to use the extra arguments > - Comprehensive tests for both user and vhostuser interfaces > > This is an RFE to gather feedback on the approach. I have a few questions > for the community: > > 1. Is this general approach of adding extraArgs reasonable, or should we > instead focus on adding specific structured fields for each passt option? No, this is not something we would add to VM XML. If there is something missing from our XML it should be added as proper attribute and or element. > 2. Should extraArgs be marked as unsupported/unstable in the documentation, > with a clear indication that it's primarily intended for development and > testing purposes? We do have similar "feature" for QEMU where you can pass any argument you want for development/testing purposes, see [1].

> 3. Are there any security concerns with allowing arbitrary arguments to be > passed to the passt binary via XML configuration? In case of QEMU we mark the VM as tainted, that means no support and users are on their own if something breaks. > 4. Would it be better to validate the arguments against a known allowlist > rather than allowing any argument string? No, if they are supposed to be used in production they should be exported as proper XML attribute/element, for development/testing it could be used for some new arguments where it doesn't make sense to have allow list hardcoded in libvirt as you would have to update that list and recompile libvirt in order to try new argument. [1] <https://libvirt.org/drvqemu.html#pass-through-of-arbitrary-qemu-commands> Pavel