On Fri, Jul 26, 2024 at 03:25:31AM -0400, 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@xxxxxxxxxx> > > > > > Signed-off-by: Andrew Melnychecnko <andrew@xxxxxxxxxx> > > > > > > > > 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. The question is how should an user know a migration is not supported? The user can be using exactly the same QEMU binary on two hosts, while there can be a tiny slight difference in host kernel version, then migration can fail between them misterously. There're too many kernel features that can be on/off when kernels are different, even if slightly. Then I don't see how someone can even identify such issue, unless one uses exactly the same host kernels on both sides.. -- Peter Xu
