Re: [PATCH] virtio-net: Add VIRTIO_NET_F_LABEL for a per-instance label

[Amanda Liem <Amanda.Liem@amd.com>]

On Mon, Aug 18, 2026 at 17:16, Parav Pandit <parav@nvidia.com> wrote:
> Please add the motivation for this addition describing what problem
> exists and how does this addition solve it.

Will do - I'll add it to the commit message in v2. Our use case is a
confidential VM whose image author ships a trusted manifest of expected
interfaces - the guest uses the label as a lookup key to associate each
device with its manifest entry before applying config. The manifest, not
the label, holds the authority. The guest corroborates the label against
the manifest rather than trusting it on its own, so it is not a channel
the host can use to steer configuration.

We'd follow the spec change with a Linux virtio-net driver patch exposing
the label via sysfs, so userspace (our manifest evaluator included) can
consume it without manifest logic in the driver. The manifest is just one
consumer - virtio need not standardize its format.

> And also have you considered querying this field via CVQ.
> If yes, than please explain the motivation to place this in config
> space.

Yes, a control virtqueue query could convey the same value. We prefer
config space because the label is a small, static, read-only property that
can be read at device init without negotiating VIRTIO_NET_F_CTRL_VQ or
standing up a control virtqueue just to retrieve it. The footprint is
bounded - the fields exist only when the feature is negotiated, and the
label is a fixed 64-byte buffer read once. (The v1 mention of PCI/MMIO/CCW
wasn't meant to distinguish config space from CVQ - both are
transport-independent.)

v2 to follow.

Thanks,
Amanda