focal kvm virtio_net set_features failed (-22)

It is affecting kernel linux-image-5.4.0-88-generic within guest and ocured after upgrading to focal. I returned to kernel Linux version 4.15.0-159-generic (bionic) within guest and virtio_net functions as expected.
The idea from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=165059#c21 did not solve the problem.

There is no 'focal' package in any current release of Ubuntu.
Assuming you meant to task against the kernel.
So moving to 'linux'.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1945868

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

The relevant part of the kern.log is already within the description. As the server is in production we needed to return to previous kernel.

Hi Markus, thanks for the report.
While the good/bad switch with the kernels suggest a reason in there, knowing more about the exact configuration of the guest would help in any case. The reason easily is that myself and million others use virtio-net in focal guests just fine, so there must be some detail to it in your case that makes it differ. Knowing that will help to understand.

So let me ask a few clarifications:
- You said 20.04 Host, so I assume you are on qemu 1:4.2-3ubuntu6.17 and libvirt 6.0.0-0ubuntu8.14 (could as well be backports and I want to be sure)
- You mentioned guest versions, but which exact host kernel version are you using when this happens?
- How did you configure your guest and especially the network adapter (libvirt XML if you use it or qemu cmdline if you use some other way to create it)
- Does this only apply to an old guest that is kept up (upgrade to 20.04 in the guest, reboot guest, but the qemu process stays since a long time?) or is it reproducible with a freshly started 20.04 guest on the same system?

Furthermore let us know if there is more when the issue happens in either of:
a) host kernel (dmesg)
b) host userspace (qemu log in /var/log/libvirt/guestname)
c) guest journal
d) host journal

From the code that complains in the guest we can check which feature it could not set.
The workaround you mentioned was about checksumming, but maybe in your case it is something different.
"wanted 0x0000008000174a29, left 0x000000800017ca29"

So it wanted to disable one, but could not.
This is already interesting as plenty of features are fixed when using virtio-net.
You can see that if you look at `$ sudo ethtool --show-features enp1s0` for example.

The list your guest request is:
tx-scatter-gather
tx-checksum-ip-generic
highdma
rx-vlan-filter
tx-generic-segmentation
rx-gro
tx-tcp-segmentation
tx-gso-robust
tx-tcp-ecn-segmentation
tx-tcp6-segmentation
(This is somewhat hard to read, so I hope this is right)

But more important is the difference which it wanted to disable but could not.
That is 0x8000 which maps via netdev_features_t to "rx-lro"

Checking an example guest that I have I see this is default on but should be switchable.
This is from the newest Ubuntu release:
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: on
$ sudo ethtool --features enp1s0 lro off
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: off
$ sudo ethtool --features enp1s0 lro on
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: on

It might be worth with your working kernel to run the above sequence to see if there it is
a) off or on by default on start
b) can be turned off/on as requested

While you have lost networking after virtio-net fails, it would be even more awesome if you could run the same sequence via e.g. "virsh console" or any other non-network access to the guest that you might have.

I was running this sequence then as cross check with Focal host and Focal guest
1. 5.4.0-86-generic
$ sudo ethtool --show-features enp1s0 | grep large
large-receive-offload: off
$ sudo ethtool --features enp1s0 lro on
$ sudo ethtool --show-features enp1s0 | grep large
large...

Could be closed meanwhile. I needed to shut kvm down on this system and can not get/generate the required reports/infos any more. It has been working with e1000 drivers last.

Thanks for the ping Markus, let us know if you run into it again on another system
e1000 as fallback is fine, but also slow IMHO.
So I hope you we can one day find what it was.

just hit it with 5.4.17-2011.6.2.el7uek.x86_64
switching to e1000 as well