On Thu Sep 17, 2026 at 11:51 AM CEST, Daniel P. Berrangé wrote: > On Thu, Sep 17, 2026 at 11:13:30AM +0200, Tim Foerster wrote: >> On Thu Sep 17, 2026 at 10:27 AM CEST, Daniel P. Berrangé wrote: >> > On Wed, Sep 16, 2026 at 05:18:05PM +0400, 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. >> >> >> >> > >> >> > 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. >> >> >> >> Let see what other people & maintainers think >> > >> > A minor nitpick about naming, on the command line and QMP command >> > we use the term 'netdev' for the modern config approach, rather >> > than "net" or "network" which is the original terminology prior >> > to "netdev". >> > >> > On the general design though, IMHO, adding such narrow commands >> > is not very desirable. >> > >> > On the input side we already have a data structure defined for >> > the input arguments to 'netdev-add', namely "Netdev", which >> > has fields for all the possible config options of all the >> > backends via a discriminated union. >> > >> > In the case of TAP devices there are two scenarios - the low >> > level backend represented in NetdevTapOptions, and the high >> > level backend rerpesented in NetdevBridgeOptions. >> > >> > The NetdevTapOptions struct already includes a "ifname" field.v >> > In the case of passing in an FD during 'netdev-add', 'fd' would >> > be set, while 'ifname' would be left unset. >> > >> > It is reasonable to say, however, then upon querying the live >> > NetdevTapOptions, *only* the "ifname" field ought to be present, >> > either the orignal value from the user, or the derived value >> > from calling tap_fd_get_ifname(). >> > >> > IOW, what I'm saying is that if we want to query the live netdv >> > backend config, we should have: >> > >> > { 'command': 'query-netdevs', 'data': ['Netdev'] } >> > >> > as a formal QAPI model. >> > >> > Aside from the general plumbing work, two things to be aware of >> > >> > * After creating the netdev initially, we throw away the >> > original "Netdev" struct data. We would need to preserve >> > that struct, so that we can later report it back with >> > query-netdevs. The TAP backend would also have to fill-in >> > the 'ifname' field when given an 'fd' initially. >> > >> > >> > * In theory someone could still be using '-net' instead >> > of '-netdev', where IIUC, we will have an "Netdev" >> > struct at any point. >> > >> > The idealized thing todo is to fold "-net" onto "-netdev" >> > by making it synthesize a "Netdev" and then go through >> > the Netdev setup code path, but their semantics aren't a >> > perfect match which is why they're separate to begin >> > with. So ignore that idea. >> > >> > The more practical thing to do is merely document that >> > 'query-netdevs' only reports on backends created via >> > '-netdev' and thus declare '-net' compatibility entirely >> > out of scope. >> >> Hi Daniel, >> >> Thanks, the generic query-netdevs approach makes sense to me. >> >> One thing I'd like to clarify is the intended scope: should this expose >> live backend details broadly for convenience, or focus on information >> an external management process cannot obtain without additional privileges? >> >> My original problem is the latter: reliably identifying the host TAP >> interface associated with a qemu netdev currently requires >> CAP_SYS_PTRACE in my setup. qemu already owns the FD and can obtain >> the name directly. > > I see it as primarily reflecting the current configuration that > QEMU runs with. That some of this information is dynamically > updated "live" such that it solves your ifname use case, is an > added benefit. > > >> I'd be comfortable starting with the current TAP interface name for >> both tap and bridge backends. I'd query it via TUNGETIFF even when >> ifname was originally supplied, since the interface may have been >> renamed on the host. > > Yes, refreshing the ifname name to cope wth renames sounds reasonable > >> Would that fit your intended scope? For bridge, would you prefer >> extending NetdevBridgeOptions with ifname, or keeping such runtime >> details in a separate query result type? > > I would extend NetdevBridgeOptions with ifname. Conceptually it > would be reasonable for the user to set a desired ifname when > requesting the bridge to begin with, but I'm not asking you to > do that, unless you really want to go down the rabbit hole. >
Alright, at least to me the scope seems quite clear. Not sure how the process goes from here. Do we wait for feedback from the (other) responsible maintainers, or is this low-hanging enough to move ahead? My goal is to just submit this patch for now and ask for help later (feel free to be harsh with your feedback, I think I can handle it), if that's okay with you. :D > > With regards, > Daniel
