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

[Peter Xu]

On Fri, Jul 26, 2024 at 07:39:46PM +0200, Thomas Huth wrote:
> 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@daynix.com>
> > > > > > Signed-off-by: Andrew Melnychecnko <andrew@daynix.com>
> > > > > 
> > > > > 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?

Probably too late for this one; this patch was merged in 8.2.
Unfortunately CIs won't even cover a test across two host kernels, even so
it'll need to be unlucky enough to one has USO one not..

But I do agree with Thomas here.

I think the only feature that can be auto-enabled is the ones that do not
affect guest ABI.  When affected, the only right way to me to enable them
should be exporting -device interface so that Libvirt can opt-in on
enabling them when the host support is detected.  For QEMU users, that
means user needs to explicitly enable them or they're off.

Or, there's also another option that we turn default to ON for such
feature, but when most of the kernels should support it.  With that, we can
set OFF in compat property for old machines, and we should fail the new
machine from boot when running on an old kenrel without the feature.

Thanks,

-- 
Peter Xu