On Fri, Sep 11, 2026 at 4:28 PM Michael S. Tsirkin <[email protected]> wrote:
>
> On Fri, Sep 11, 2026 at 04:11:33PM +0800, Peng Hao wrote:
> > From: Peng Hao <[email protected]>
> >
> > Since commit 69b9461512246 ("virtio_pci_modern: allow configuring
> > extended features") the modern virtio-pci driver unconditionally
> > accesses the whole 128 bits features space, i.e. it drives
> > device_feature_select / guest_feature_select with the values 0..3.
> >
> > Devices predating the extended features space only implement the
> > legacy 64 bits one, and what they report for the selectors above it is
> > not a valid features space.
>
>
> That's a device bug then? The spec says:
>
> \begin{description}
> \item[\field{device_feature_select}]
> The driver uses this to select which feature bits
> \field{device_feature} shows.
> Value 0x0 selects Feature Bits 0 to 31, 0x1 selects Feature Bits 32
> to 63, etc.
>
> that "etc" means any value is valid)
>
> There's no "extended features space". It's a quick hack we did
> in the virtio code to avoid changing all drivers, but the spec
> treats all features uniformly.
>
>
> So you have a device that ignores a feature selector? Or some specific
> bits from it?
It ignores every bit of the selector but bit 0, so the selector values 2
and 3 alias 0 and 1.Reading the four dwords back on the virtio_net
device of the smartNIC:
device_feature[0..3] = 0x1043882b 0x80000023 0x1043882b 0x80000023
\------------ real
--------------/\---------- aliased ----------/
What that costs in practice, for virtio_net:
bit 1 VIRTIO_NET_F_GUEST_CSUM aliases onto
bit 65 VIRTIO_NET_F_GUEST_UDP_TUNNEL_GSO
bit 3 VIRTIO_NET_F_MTU aliases onto
bit 67 VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO
Both are in the driver's feature table, so the driver offers them back,
the AND keeps them, and virtnet_probe() takes the first branch here:
if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_UDP_TUNNEL_GSO) ||
virtio_has_feature(vdev, VIRTIO_NET_F_HOST_UDP_TUNNEL_GSO))
vi->hdr_len = sizeof(struct virtio_net_hdr_v1_hash_tunnel);
24 bytes of header where the device uses the 12 of
virtio_net_hdr_mrg_rxbuf, on every buffer in both directions, plus
vi->rx_tnl and vi->tx_tnl set. The link comes up and carries no
traffic.
The same card works fine on 6.6. 6.6 simply never drives the
selectors 2 and 3, so the aliasing stays latent.
> > Negotiating it makes the driver and the
> > device end up with different features sets: on a smart NIC exposing a
> > virtio_net device the link comes up but carries no traffic, while the
> > same device works with a kernel that only accesses the low 64 bits.
> >
> > Reading the features space has no side effect, so keep reading all of
> > it and use the extended part to tell whether the device implements it:
> > report the legacy 64 bits only when the extended words read back as
> > all-ones or as an alias of the low words, and latch the device down for
> > good.
>
> So using all bits is illegal, and so is anything that will by luck
> mirror low bits?
>
> This is really VIRTIO_F_BAD_FEATURE mess replaying itself.
>
> Really quite a hack :(
>
Agreed, I have recognized this issue.
>
>
> > As the features negotiation ANDs the device and driver features,
> > no feature above bit 63 can be negotiated afterwards.
> >
> > Writing a selector the device does not implement cannot be relied upon
> > the same way, so never drive one above the highest word that actually
> > carries a bit.
>
> This part is ok.
>
> > The reset preceding the features negotiation zeroes the
> > device side features, hence the words left unwritten stay cleared.
> >
> > Also dump the raw device_feature dwords,
>
> dump?
>
The dump was debug residue and the parameter was me not
knowing how to identify the device.
> > and add a max_features_u64s
> > module parameter to force the legacy 64 bits space on devices whose
> > quirk the detection does not catch.
>
> This is even worse.
>
>
> > Conforming devices are unaffected: their extended words are neither
> > all-ones nor an alias of the low ones, so the detection does not
> > trigger.
> >
> > Signed-off-by: Peng Hao <[email protected]>
>
> Can you simply fix the device please? Why not?
>
I would need to know more about the hardware specifics to determine
if a hardware-level fix is possible, but that wouldn't help the cards
already in the field.
I will investigate whether the issue can be resolved via a hardware quirk.
Thanks.
