Hi, On Wed Sep 16, 2026 at 3:18 PM CEST, Marc-André Lureau wrote: > Hi > > On Wed, Sep 16, 2026 at 10:22 AM Tim Foerster via qemu development > <[email protected]> wrote: >> >> Hi, >> >> I'd like to query the host TAP interface name of a network backend via QMP, >> especially when the TAP FD is passed to QEMU using SCM_RIGHTS >> and then assigned to a backend through fd=. >> >> In my current setup, retrieving this information externally requires >> CAP_SYS_PTRACE. This gives the management process far more access >> than needed and conflicts with the Landlock sandboxing I want to apply, due >> to Landlock's ptrace restrictions [1]. >> >> QEMU already owns the FD, and tap_fd_get_ifname() can retrieve the name >> using TUNGETIFF on Linux. For a TAP passed through fd=, x-query- >> network currently reports the following (simplified): >> >> { >> "name": "hostnet0", >> "type": "tap", >> "info-str": "fd=42" >> } >> >> I'd like to obtain the actual interface name in a structured field, >> regardless of how the TAP was created or passed to QEMU. For example: >> >> { >> "name": "hostnet0", >> "type": "tap", >> "info-str": "fd=42", >> "data": { >> "ifname": "vnet7" >> } >> } >> >> Would extending x-query-network be the preferred approach? If so, would you >> prefer a dedicated ifname field or a type-specific data object >> selected by the existing type field? > > x- QMP commands are not meant for any other usage than debugging and > testing (in fact, we should probably exclude them in production > builds!). In particular, this command is currently only meant to be a > HMP "info network" substitute for test/debugging only atm.
Well, I know about this concern, I was mainly trying to open a door there. Not sure how flexible we will end up being here. I also did not get into which patterns should be part of the HMP and which should only be exposed to the QMP layer. >> >> Personally, I'd prefer an approach that is reasonably easy to backport >> downstream to older QEMU releases. Since x-query-network is >> relatively new, extending it would also require bringing that command to >> releases which don't have it yet, potentially increasing the >> backporting effort. >> >> A type-specific data object could also accommodate additional TAP properties >> later, such as multiqueue mode or vnet_hdr. However, those >> are outside my current scope, I only need the interface name. > > I'd suggest a new query-network-tap(name: hostnet0) -> TAPInfo command > for your specific case. Eventually, later, NetworkClientInfo could > later embed that data. I like the idea of having a `query-network-tap(name: hostnet0)`. I can also try to send a patch, but wanted to collect your opinions first. Once we agree on an API layout, I'll give it a try. > > Let see what other people & maintainers think > > thanks
