On Thu, Nov 6, 2025 at 10:33 PM Jinpu Wang <[email protected]> wrote: > > Hi Jason, > > On Thu, Nov 6, 2025 at 5:05 AM Jason Wang <[email protected]> wrote: > > > > x > > > > On Thu, Nov 6, 2025 at 6:17 AM Peter Xu <[email protected]> wrote: > > > > > > On Wed, Nov 05, 2025 at 10:27:59AM +0100, Jinpu Wang wrote: > > > > > > These are not present (or not supported) on QEMU 8.2.10, which > > > > > > causes > > > > > > the migration state load to fail. > > > > > > > > > > Interesting, we've already done the compat work: > > > > > > > > > > GlobalProperty hw_compat_8_1[] = { > > > > > { TYPE_PCI_BRIDGE, "x-pci-express-writeable-slt-bug", "true" }, > > > > > { "ramfb", "x-migrate", "off" }, > > > > > { "vfio-pci-nohotplug", "x-ramfb-migrate", "off" }, > > > > > { "igb", "x-pcie-flr-init", "off" }, > > > > > { TYPE_VIRTIO_NET, "host_uso", "off"}, > > > > > { TYPE_VIRTIO_NET, "guest_uso4", "off"}, > > > > > { TYPE_VIRTIO_NET, "guest_uso6", "off"}, > > > > > }; > > > > > const size_t hw_compat_8_1_len = G_N_ELEMENTS(hw_compat_8_1); > > > > Yeah, I noticed the same. > > > > > > AFAICT, this is a known issue.. > > > > > > Thomas and I used to suggest we should not turn on USO* by default by > > > probing kernel, but only allow user choosing it explicitly in a VM > > > setup. IOW, dest qemu should stop booting at all when kernel is too old > > > (when user chose the feature). > > > > > > See: > > > > > > https://lore.kernel.org/all/ZqQNKZ9_OPhDq2AK@x1n/ > > > > > > Thanks, > > > > I see, so the reason is that the destination doesn't support USO in > > the kernel. For those kinds of features that depend on the kernel, I > > agree to disable them by default. But I'm not sure if it's too late or > > maybe we can do strict peer feature check like this in > > virtio_net_get_features(): > > > > if (!peer_has_uso(n)) { > > - virtio_clear_feature_ex(features, VIRTIO_NET_F_HOST_USO); > > - virtio_clear_feature_ex(features, VIRTIO_NET_F_GUEST_USO4); > > - virtio_clear_feature_ex(features, VIRTIO_NET_F_GUEST_USO6); > > + if (n->strict_peer_feature_check) { > > + if (virtio_has_feature_ex(features, VIRTIO_NET_F_HOST_USO) | > > + virtio_has_feature_ex(features, VIRTIO_NET_F_GUEST_USO4) | > > + virtio_has_feature_ex(features, VIRTIO_NET_F_GUEST_USO6)) > > + error_setg(errp, "virtio_net: peer doesn't support USO"); > > + } else { > > + virtio_clear_feature_ex(features, VIRTIO_NET_F_HOST_USO); > > + virtio_clear_feature_ex(features, VIRTIO_NET_F_GUEST_USO4); > > + virtio_clear_feature_ex(features, VIRTIO_NET_F_GUEST_USO6); > > + } > > } > > > is there any document to learn how the feature checking works, > function like peer_has_uso, what is the peer exactly in this context,
It's the peer of virtio-net NIC which is the "backend". In your context, it should be tap. > is it the migration target or host kernel? This aims to fail the qemu launch if the feature required is not satisfied by the perr. Let me post a formal RFC for this. Thanks > > So qemu would fail earlier than fail the migration. > > > > Thanks > > Thx! > > > > > > > > > > -- > > > Peter Xu > > > > > >
