Re: [PATCH v2 4/4] virtio-net: Add support for USO features

On 26/07/2024 09.25, Michael S. Tsirkin wrote: > On Fri, Jul 26, 2024 at 09:03:24AM +0200, Thomas Huth wrote: > > On 26/07/2024 08.08, Michael S. Tsirkin wrote: > > > On Thu, Jul 25, 2024 at 06:18:20PM -0400, Peter Xu wrote: > > > > On Tue, Aug 01, 2023 at 01:31:48AM +0300, Yuri Benditovich wrote: > > > > > USO features of virtio-net device depend on kernel ability > > > > > to support them, for backward compatibility by default the > > > > > features are disabled on 8.0 and earlier. > > > > > > > > > > Signed-off-by: Yuri Benditovich <yuri.benditovich(a)daynix.com&gt; > > > > > Signed-off-by: Andrew Melnychecnko <andrew(a)daynix.com&gt; > > > > > > > > Looks like this patch broke migration when the VM starts on a host that has > > > > USO supported, to another host that doesn't.. > > > > > > This was always the case with all offloads. The answer at the moment is, > > > don't do this. > > > > May I ask for my understanding: > > "don't do this" = don't automatically enable/disable virtio features in QEMU > > depending on host kernel features, or "don't do this" = don't try to migrate > > between machines that have different host kernel features? > > The later. From my experience, it should rather be the former. We've seen similar issues with the s390x machine in the past when trying to automatically enable features depending on the availability of a kernel features. While it looks nicer at a very first glance ("hey, a new feature is available, we enable that for you, dear user!"), you end up in migration hell pretty quickly. Maybe we could elevate the "--nodefaults" command line switch to avoid enabling such features automatically? Anyway, while we're discussing solutions: We are in softfreeze already. Should we disable the UFO bits in the new 9.1 machine type for the time being to avoid that more people are running into this problem?