[BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Jinpu Wang]

Hello QEMU developers,

I’m encountering a migration failure when trying to live-migrate a VM
from a newer host (kernel 6.12 + QEMU 9.2.4) to an older one (kernel
6.1 + QEMU 8.2.10).
Migration in the forward direction (old → new) works fine, but after
rebooting the guest on the new host, migration back to the old host
fails.

________________________________

Issue summary

Source host: kernel 6.12, QEMU 9.2.4

Destination host: kernel 6.1, QEMU 8.2.10

VM type: pc-q35-8.2, using virtio-net-pci with vhost backend

Symptom: Migration from 9.2.4 → 8.2.10 fails with virtio-net load error.

Error log (destination):

2025-09-23T07:06:14.915708Z qemu-8.2: Features 0x1c0010130afffa7
unsupported. Allowed features: 0x179bfffe7
2025-09-23T07:06:14.915843Z qemu-8.2: Failed to load virtio-net:virtio
2025-09-23T07:06:14.915851Z qemu-8.2: error while loading state for
instance 0x0 of device '0000:00:02.0:06.0/virtio-net'
2025-09-23T07:06:14.917894Z qemu-8.2: load of migration failed:
Operation not permitted

________________________________

Analysis

It appears that virtio-net feature bits differ between the two versions.
On QEMU 9.2.4, virtio-net reports additional features:

VIRTIO_F_RING_RESET

VIRTIO_NET_F_HOST_USO

VIRTIO_NET_F_GUEST_USO4

VIRTIO_NET_F_GUEST_USO6

These are not present (or not supported) on QEMU 8.2.10, which causes
the migration state load to fail.

The issue seems related to the introduction of these features and how
they are handled during incoming migration when the target QEMU does
not recognize them.

________________________________

Reproduction steps

Start VM on host with QEMU 8.2.10 (kernel 6.1).

Migrate to host with QEMU 9.2.4 (kernel 6.12).
→ Migration succeeds.

Reboot the guest on the 9.2.4 host.

Attempt to migrate back to QEMU 8.2.10 host.
→ Migration fails with virtio-net load error (see log above).

________________________________

Expected behavior

Migration from newer QEMU to older version should either:

gracefully ignore unsupported virtio-net features, or

fail with a clear compatibility message before starting migration.

Currently, migration starts and fails during device state load.

________________________________

Related patch

I found this commit that looks relevant but is already included in
both 8.2.10 and 9.2.4:

https://lore.kernel.org/qemu-devel/20240527072435.52812-15-mjt@tls.msk.ru/

________________________________

VM configuration

-uuid dbaf0b1f-4dc5-4462-86b1-d82107b58599
-name Serverwittchendbaf0b1f-4dc5-4462-86b1-d82107b58599
-M pc-q35-8.2
-accel kvm,kernel-irqchip=split
-cpu SierraForest-v2
-smp 7,sockets=128,cores=1,maxcpus=128,threads=1
-m 4096,slots=252,maxmem=256G
-bios /usr/share/ovmf/OVMF.fd
-device virtio-net-pci,netdev=hostnet6,id=net6,mac=02:01:17:9b:9a:35,bus=pci.0,addr=0x6
-netdev tap,ifname=n0201179b9a35,id=hostnet6,script=no,downscript=no

________________________________

Question

Is this expected behavior (i.e. migration incompatibility due to newer
virtio-net feature bits)?
Or should QEMU handle such feature mismatches more gracefully (e.g.,
automatically disable unsupported virtio features during migration)?

Any guidance on how to make migration between these versions work
would be appreciated.

________________________________

Thanks,
Jinpu Wang @ IONOS Cloud

Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Jason Wang]

On Wed, Nov 5, 2025 at 4:49 PM Jinpu Wang <jinpu.wang@ionos.com> wrote:
>
> Hello QEMU developers,
>
> I’m encountering a migration failure when trying to live-migrate a VM
> from a newer host (kernel 6.12 + QEMU 9.2.4) to an older one (kernel
> 6.1 + QEMU 8.2.10).
> Migration in the forward direction (old → new) works fine, but after
> rebooting the guest on the new host, migration back to the old host
> fails.
>
> ________________________________
>
> Issue summary
>
> Source host: kernel 6.12, QEMU 9.2.4
>
> Destination host: kernel 6.1, QEMU 8.2.10
>
> VM type: pc-q35-8.2, using virtio-net-pci with vhost backend
>
> Symptom: Migration from 9.2.4 → 8.2.10 fails with virtio-net load error.
>
> Error log (destination):
>
> 2025-09-23T07:06:14.915708Z qemu-8.2: Features 0x1c0010130afffa7
> unsupported. Allowed features: 0x179bfffe7
> 2025-09-23T07:06:14.915843Z qemu-8.2: Failed to load virtio-net:virtio
> 2025-09-23T07:06:14.915851Z qemu-8.2: error while loading state for
> instance 0x0 of device '0000:00:02.0:06.0/virtio-net'
> 2025-09-23T07:06:14.917894Z qemu-8.2: load of migration failed:
> Operation not permitted
>
> ________________________________
>
> Analysis
>
> It appears that virtio-net feature bits differ between the two versions.
> On QEMU 9.2.4, virtio-net reports additional features:
>
> VIRTIO_F_RING_RESET
>
> VIRTIO_NET_F_HOST_USO
>
> VIRTIO_NET_F_GUEST_USO4
>
> VIRTIO_NET_F_GUEST_USO6
>
> 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);

>
> The issue seems related to the introduction of these features and how
> they are handled during incoming migration when the target QEMU does
> not recognize them.
>
> ________________________________
>
> Reproduction steps
>
> Start VM on host with QEMU 8.2.10 (kernel 6.1).
>
> Migrate to host with QEMU 9.2.4 (kernel 6.12).
> → Migration succeeds.
>
> Reboot the guest on the 9.2.4 host.
>
> Attempt to migrate back to QEMU 8.2.10 host.
> → Migration fails with virtio-net load error (see log above).
>
> ________________________________
>
> Expected behavior
>
> Migration from newer QEMU to older version should either:
>
> gracefully ignore unsupported virtio-net features, or
>
> fail with a clear compatibility message before starting migration.
>
> Currently, migration starts and fails during device state load.
>
> ________________________________
>
> Related patch
>
> I found this commit that looks relevant but is already included in
> both 8.2.10 and 9.2.4:
>
> https://lore.kernel.org/qemu-devel/20240527072435.52812-15-mjt@tls.msk.ru/
>
> ________________________________
>
> VM configuration
>
> -uuid dbaf0b1f-4dc5-4462-86b1-d82107b58599
> -name Serverwittchendbaf0b1f-4dc5-4462-86b1-d82107b58599
> -M pc-q35-8.2

Could you double check if this is used in both source and destination?

> -accel kvm,kernel-irqchip=split
> -cpu SierraForest-v2
> -smp 7,sockets=128,cores=1,maxcpus=128,threads=1
> -m 4096,slots=252,maxmem=256G
> -bios /usr/share/ovmf/OVMF.fd
> -device virtio-net-pci,netdev=hostnet6,id=net6,mac=02:01:17:9b:9a:35,bus=pci.0,addr=0x6
> -netdev tap,ifname=n0201179b9a35,id=hostnet6,script=no,downscript=no
>
> ________________________________
>
> Question
>
> Is this expected behavior (i.e. migration incompatibility due to newer
> virtio-net feature bits)?

No.

Could you check if

1) those features were enabled or not via "info qtree" when using pc-q35-8.2.
2) whether the migration with if you disabled those features explicitly in 9.2.4

> Or should QEMU handle such feature mismatches more gracefully (e.g.,
> automatically disable unsupported virtio features during migration)?

This would break guests as it could be noticed by guests.

>
> Any guidance on how to make migration between these versions work
> would be appreciated.
>
> ________________________________
>
> Thanks,
> Jinpu Wang @ IONOS Cloud
>

Thanks

Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Jinpu Wang]

Hi Jason,

Thank you for reply.
On Wed, Nov 5, 2025 at 9:59 AM Jason Wang <jasowang@redhat.com> wrote:
>
> On Wed, Nov 5, 2025 at 4:49 PM Jinpu Wang <jinpu.wang@ionos.com> wrote:
> >
> > Hello QEMU developers,
> >
> > I’m encountering a migration failure when trying to live-migrate a VM
> > from a newer host (kernel 6.12 + QEMU 9.2.4) to an older one (kernel
> > 6.1 + QEMU 8.2.10).
> > Migration in the forward direction (old → new) works fine, but after
> > rebooting the guest on the new host, migration back to the old host
> > fails.
> >
> > ________________________________
> >
> > Issue summary
> >
> > Source host: kernel 6.12, QEMU 9.2.4
> >
> > Destination host: kernel 6.1, QEMU 8.2.10
> >
> > VM type: pc-q35-8.2, using virtio-net-pci with vhost backend
> >
> > Symptom: Migration from 9.2.4 → 8.2.10 fails with virtio-net load error.
> >
> > Error log (destination):
> >
> > 2025-09-23T07:06:14.915708Z qemu-8.2: Features 0x1c0010130afffa7
> > unsupported. Allowed features: 0x179bfffe7
> > 2025-09-23T07:06:14.915843Z qemu-8.2: Failed to load virtio-net:virtio
> > 2025-09-23T07:06:14.915851Z qemu-8.2: error while loading state for
> > instance 0x0 of device '0000:00:02.0:06.0/virtio-net'
> > 2025-09-23T07:06:14.917894Z qemu-8.2: load of migration failed:
> > Operation not permitted
> >
> > ________________________________
> >
> > Analysis
> >
> > It appears that virtio-net feature bits differ between the two versions.
> > On QEMU 9.2.4, virtio-net reports additional features:
> >
> > VIRTIO_F_RING_RESET
> >
> > VIRTIO_NET_F_HOST_USO
> >
> > VIRTIO_NET_F_GUEST_USO4
> >
> > VIRTIO_NET_F_GUEST_USO6
> >
> > 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.
>
> >
> > The issue seems related to the introduction of these features and how
> > they are handled during incoming migration when the target QEMU does
> > not recognize them.
> >
> > ________________________________
> >
> > Reproduction steps
> >
> > Start VM on host with QEMU 8.2.10 (kernel 6.1).
> >
> > Migrate to host with QEMU 9.2.4 (kernel 6.12).
> > → Migration succeeds.
> >
> > Reboot the guest on the 9.2.4 host.
> >
> > Attempt to migrate back to QEMU 8.2.10 host.
> > → Migration fails with virtio-net load error (see log above).
> >
> > ________________________________
> >
> > Expected behavior
> >
> > Migration from newer QEMU to older version should either:
> >
> > gracefully ignore unsupported virtio-net features, or
> >
> > fail with a clear compatibility message before starting migration.
> >
> > Currently, migration starts and fails during device state load.
> >
> > ________________________________
> >
> > Related patch
> >
> > I found this commit that looks relevant but is already included in
> > both 8.2.10 and 9.2.4:
> >
> > https://lore.kernel.org/qemu-devel/20240527072435.52812-15-mjt@tls.msk.ru/
> >
> > ________________________________
> >
> > VM configuration
> >
> > -uuid dbaf0b1f-4dc5-4462-86b1-d82107b58599
> > -name Serverwittchendbaf0b1f-4dc5-4462-86b1-d82107b58599
> > -M pc-q35-8.2
>
> Could you double check if this is used in both source and destination?
>
> > -accel kvm,kernel-irqchip=split
> > -cpu SierraForest-v2
> > -smp 7,sockets=128,cores=1,maxcpus=128,threads=1
> > -m 4096,slots=252,maxmem=256G
> > -bios /usr/share/ovmf/OVMF.fd
> > -device virtio-net-pci,netdev=hostnet6,id=net6,mac=02:01:17:9b:9a:35,bus=pci.0,addr=0x6
> > -netdev tap,ifname=n0201179b9a35,id=hostnet6,script=no,downscript=no
> >
> > ________________________________
> >
> > Question
> >
> > Is this expected behavior (i.e. migration incompatibility due to newer
> > virtio-net feature bits)?
>
> No.
>
> Could you check if
>
> 1) those features were enabled or not via "info qtree" when using pc-q35-8.2.
here is output on the machine with 9.2.4, all uso features are enabled:
jwang@ps404a-16.stg:~$ nc -U
/opt/profitbricks/vcb/pbkvm/mon/791776d3-72cc-4392-8603-bb5bdc537011.sock
{"QMP": {"version": {"qemu": {"micro": 4, "minor": 2, "major": 9},
"package": ""}, "capabilities": ["oob"]}}
{'execute':'qmp_capabilities'}
{"return": {}}
{'execute':'human-monitor-command','arguments':{'command-line':'info virtio'}}
{"return": "/machine/peripheral-anon/device[1]/virtio-backend
[virtio-rng]\r\n/machine/peripheral/virtio-disk5/virtio-backend
[virtio-blk]\r\n/machine/peripheral/virtio-disk7/virtio-backend
[virtio-blk]\r\n/machine/peripheral/net6/virtio-backend
[virtio-net]\r\n"}
{'execute':'human-monitor-command','arguments':{'command-line':'info qtree'}
}
{"return": "bus: main-system-bus\r\n  type System\r\n  dev: ps2-mouse,
id \"\"\r\n    gpio-out \"\" 1\r\n  dev: ps2-kbd, id \"\"\r\n
gpio-out \"\" 1\r\n  dev: hpet, id \"\"\r\n    gpio-in \"\" 2\r\n
gpio-out \"\" 1\r\n    gpio-out \"sysbus-irq\" 32\r\n    timers = 3
(0x3)\r\n    msi = false\r\n    hpet-intcap = 16711940 (0xff0104)\r\n
  hpet-offset-saved = true\r\n    mmio
00000000fed00000/0000000000000400\r\n  dev: ioapic, id \"\"\r\n
gpio-in \"\" 24\r\n    version = 32 (0x20)\r\n    mmio
00000000fec00000/0000000000001000\r\n  dev: q35-pcihost, id \"\"\r\n
 MCFG = 3758096384 (0xe0000000)\r\n    pci-hole64-size = 34359738368
(32 GiB)\r\n    below-4g-mem-size = 2147483648 (2 GiB)\r\n
above-4g-mem-size = 2147483648 (2 GiB)\r\n    smm-ranges = true\r\n
x-pci-hole64-fix = true\r\n    x-config-reg-migration-enabled =
true\r\n    bypass-iommu = false\r\n    bus: pcie.0\r\n      type
PCIE\r\n      dev: pcie-root-port, id \"rp.2\"\r\n
x-migrate-msix = true\r\n        bus-reserve = 4294967295
(0xffffffff)\r\n        io-reserve = 18446744073709551615 (16 EiB)\r\n
       mem-reserve = 18446744073709551615 (16 EiB)\r\n
pref32-reserve = 18446744073709551615 (16 EiB)\r\n
pref64-reserve = 18446744073709551615 (16 EiB)\r\n        x-speed =
\"16\"\r\n        x-width = \"32\"\r\n        power_controller_present
= true\r\n        disable-acs = false\r\n        chassis = 0 (0x0)\r\n
       slot = 1 (0x1)\r\n        hotplug = true\r\n
x-do-not-expose-native-hotplug-cap = false\r\n        port = 0
(0x0)\r\n        aer_log_max = 8 (0x8)\r\n
x-pci-express-writeable-slt-bug = false\r\n        addr = 04.0\r\n
   romfile = \"\"\r\n        romsize = 4294967295 (0xffffffff)\r\n
   rombar = 1 (0x1)\r\n        multifunction = false\r\n
x-pcie-lnksta-dllla = true\r\n        x-pcie-extcap-init = true\r\n
    failover_pair_id = \"\"\r\n        acpi-index = 0 (0x0)\r\n
x-pcie-err-unc-mask = true\r\n        x-pcie-ari-nextfn-1 = false\r\n
      x-max-bounce-buffer-size = 4096 (4 KiB)\r\n
x-pcie-ext-tag = false\r\n        busnr = 0 (0x0)\r\n        class PCI
bridge, addr 00:04.0, pci id 1b36:000c (sub 0080:0000)\r\n        bar
0: mem at 0x88644000 [0x88644fff]\r\n        bus: rp.2\r\n
type PCIE\r\n      dev: pcie-root-port, id \"rp.1\"\r\n
x-migrate-msix = true\r\n        bus-reserve = 4294967295
(0xffffffff)\r\n        io-reserve = 18446744073709551615 (16 EiB)\r\n
       mem-reserve = 18446744073709551615 (16 EiB)\r\n
pref32-reserve = 18446744073709551615 (16 EiB)\r\n
pref64-reserve = 18446744073709551615 (16 EiB)\r\n        x-speed =
\"16\"\r\n        x-width = \"32\"\r\n        power_controller_present
= true\r\n        disable-acs = false\r\n        chassis = 0 (0x0)\r\n
       slot = 0 (0x0)\r\n        hotplug = true\r\n
x-do-not-expose-native-hotplug-cap = false\r\n        port = 0
(0x0)\r\n        aer_log_max = 8 (0x8)\r\n
x-pci-express-writeable-slt-bug = false\r\n        addr = 03.0\r\n
   romfile = \"\"\r\n        romsize = 4294967295 (0xffffffff)\r\n
   rombar = 1 (0x1)\r\n        multifunction = false\r\n
x-pcie-lnksta-dllla = true\r\n        x-pcie-extcap-init = true\r\n
    failover_pair_id = \"\"\r\n        acpi-index = 0 (0x0)\r\n
x-pcie-err-unc-mask = true\r\n        x-pcie-ari-nextfn-1 = false\r\n
      x-max-bounce-buffer-size = 4096 (4 KiB)\r\n
x-pcie-ext-tag = false\r\n        busnr = 0 (0x0)\r\n        class PCI
bridge, addr 00:03.0, pci id 1b36:000c (sub 0080:0000)\r\n        bar
0: mem at 0x88645000 [0x88645fff]\r\n        bus: rp.1\r\n
type PCIE\r\n      dev: pcie-pci-bridge, id \"pci.0\"\r\n        msi =
\"auto\"\r\n        x-pci-express-writeable-slt-bug = false\r\n
addr = 02.0\r\n        romfile = \"\"\r\n        romsize = 4294967295
(0xffffffff)\r\n        rombar = 1 (0x1)\r\n        multifunction =
false\r\n        x-pcie-lnksta-dllla = true\r\n
x-pcie-extcap-init = true\r\n        failover_pair_id = \"\"\r\n
 acpi-index = 0 (0x0)\r\n        x-pcie-err-unc-mask = true\r\n
x-pcie-ari-nextfn-1 = false\r\n        x-max-bounce-buffer-size = 4096
(4 KiB)\r\n        x-pcie-ext-tag = false\r\n        busnr = 0
(0x0)\r\n        class PCI bridge, addr 00:02.0, pci id 1b36:000e (sub
0080:0000)\r\n        bar 0: mem at 0x8000100000 [0x80001000ff]\r\n
    bus: pci.0\r\n          type PCI\r\n          dev: virtio-blk-pci,
id \"virtio-disk7\"\r\n            disable-legacy = \"off\"\r\n
    disable-modern = false\r\n            class = 0 (0x0)\r\n
  ioeventfd = true\r\n            vectors = 3 (0x3)\r\n
virtio-pci-bus-master-bug-migration = false\r\n
migrate-extra = true\r\n            modern-pio-notify = false\r\n
      x-disable-pcie = false\r\n            page-per-vq = false\r\n
        x-ignore-backend-features = false\r\n            ats =
false\r\n            x-ats-page-aligned = true\r\n
x-pcie-deverr-init = true\r\n            x-pcie-lnkctl-init = true\r\n
           x-pcie-pm-init = true\r\n
x-pcie-pm-no-soft-reset = false\r\n            x-pcie-flr-init =
true\r\n            aer = false\r\n            addr = 07.0\r\n
   romfile = \"\"\r\n            romsize = 4294967295 (0xffffffff)\r\n
           rombar = 1 (0x1)\r\n            multifunction = false\r\n
         x-pcie-lnksta-dllla = true\r\n            x-pcie-extcap-init
= true\r\n            failover_pair_id = \"\"\r\n
acpi-index = 0 (0x0)\r\n            x-pcie-err-unc-mask = true\r\n
       x-pcie-ari-nextfn-1 = false\r\n
x-max-bounce-buffer-size = 4096 (4 KiB)\r\n            x-pcie-ext-tag
= false\r\n            busnr = 1 (0x1)\r\n            class SCSI
controller, addr 01:07.0, pci id 1af4:1001 (sub 1af4:0002)\r\n
   bar 0: i/o at 0x6000 [0x607f]\r\n            bar 1: mem at
0x88400000 [0x88400fff]\r\n            bar 4: mem at 0x8000000000
[0x8000003fff]\r\n            bus: virtio-bus\r\n              type
virtio-pci-bus\r\n              dev: virtio-blk-device, id \"\"\r\n
            drive = \"drive-virtio-disk7\"\r\n
backend_defaults = \"auto\"\r\n                logical_block_size =
512 (512 B)\r\n                physical_block_size = 512 (512 B)\r\n
             min_io_size = 0 (0 B)\r\n                opt_io_size = 0
(0 B)\r\n                discard_granularity = 4294967295 (4 GiB)\r\n
              write-cache = \"auto\"\r\n                share-rw =
false\r\n                account-invalid = \"auto\"\r\n
account-failed = \"auto\"\r\n                rerror = \"auto\"\r\n
           werror = \"auto\"\r\n                cyls = 16383
(0x3fff)\r\n                heads = 16 (0x10)\r\n                secs
= 63 (0x3f)\r\n                lcyls = 0 (0x0)\r\n
lheads = 0 (0x0)\r\n                lsecs = 0 (0x0)\r\n
serial = \"b663a1b71b486d62\"\r\n                config-wce = true\r\n
               request-merging = true\r\n                num-queues =
2 (0x2)\r\n                queue-size = 256 (0x100)\r\n
seg-max-adjust = true\r\n                iothread-vq-mapping =
<null>\r\n                discard = false\r\n
report-discard-granularity = true\r\n                write-zeroes =
true\r\n                max-discard-sectors = 4194303 (0x3fffff)\r\n
             max-write-zeroes-sectors = 4194303 (0x3fffff)\r\n
       x-enable-wce-if-config-wce = true\r\n
indirect_desc = true\r\n                event_idx = true\r\n
     notify_on_empty = true\r\n                any_layout = true\r\n
             iommu_platform = false\r\n                packed =
false\r\n                queue_reset = true\r\n
in_order = false\r\n                use-started = true\r\n
   use-disabled-flag = true\r\n                x-disable-legacy-check
= false\r\n          dev: virtio-blk-pci, id \"virtio-disk5\"\r\n
      disable-legacy = \"off\"\r\n            disable-modern =
false\r\n            class = 0 (0x0)\r\n            ioeventfd =
true\r\n            vectors = 3 (0x3)\r\n
virtio-pci-bus-master-bug-migration = false\r\n
migrate-extra = true\r\n            modern-pio-notify = false\r\n
      x-disable-pcie = false\r\n            page-per-vq = false\r\n
        x-ignore-backend-features = false\r\n            ats =
false\r\n            x-ats-page-aligned = true\r\n
x-pcie-deverr-init = true\r\n            x-pcie-lnkctl-init = true\r\n
           x-pcie-pm-init = true\r\n
x-pcie-pm-no-soft-reset = false\r\n            x-pcie-flr-init =
true\r\n            aer = false\r\n            addr = 05.0\r\n
   romfile = \"\"\r\n            romsize = 4294967295 (0xffffffff)\r\n
           rombar = 1 (0x1)\r\n            multifunction = false\r\n
         x-pcie-lnksta-dllla = true\r\n            x-pcie-extcap-init
= true\r\n            failover_pair_id = \"\"\r\n
acpi-index = 0 (0x0)\r\n            x-pcie-err-unc-mask = true\r\n
       x-pcie-ari-nextfn-1 = false\r\n
x-max-bounce-buffer-size = 4096 (4 KiB)\r\n            x-pcie-ext-tag
= false\r\n            busnr = 1 (0x1)\r\n            class SCSI
controller, addr 01:05.0, pci id 1af4:1001 (sub 1af4:0002)\r\n
   bar 0: i/o at 0x6080 [0x60ff]\r\n            bar 1: mem at
0x88402000 [0x88402fff]\r\n            bar 4: mem at 0x8000008000
[0x800000bfff]\r\n            bus: virtio-bus\r\n              type
virtio-pci-bus\r\n              dev: virtio-blk-device, id \"\"\r\n
            drive = \"drive-virtio-disk5\"\r\n
backend_defaults = \"auto\"\r\n                logical_block_size =
512 (512 B)\r\n                physical_block_size = 512 (512 B)\r\n
             min_io_size = 0 (0 B)\r\n                opt_io_size = 0
(0 B)\r\n                discard_granularity = 4294967295 (4 GiB)\r\n
              write-cache = \"auto\"\r\n                share-rw =
false\r\n                account-invalid = \"auto\"\r\n
account-failed = \"auto\"\r\n                rerror = \"auto\"\r\n
           werror = \"auto\"\r\n                cyls = 16383
(0x3fff)\r\n                heads = 16 (0x10)\r\n                secs
= 63 (0x3f)\r\n                lcyls = 0 (0x0)\r\n
lheads = 0 (0x0)\r\n                lsecs = 0 (0x0)\r\n
serial = \"2ea4900a095b1012\"\r\n                config-wce = true\r\n
               request-merging = true\r\n                num-queues =
2 (0x2)\r\n                queue-size = 256 (0x100)\r\n
seg-max-adjust = true\r\n                iothread-vq-mapping =
<null>\r\n                discard = false\r\n
report-discard-granularity = true\r\n                write-zeroes =
true\r\n                max-discard-sectors = 4194303 (0x3fffff)\r\n
             max-write-zeroes-sectors = 4194303 (0x3fffff)\r\n
       x-enable-wce-if-config-wce = true\r\n
indirect_desc = true\r\n                event_idx = true\r\n
     notify_on_empty = true\r\n                any_layout = true\r\n
             iommu_platform = false\r\n                packed =
false\r\n                queue_reset = true\r\n
in_order = false\r\n                use-started = true\r\n
   use-disabled-flag = true\r\n                x-disable-legacy-check
= false\r\n          dev: virtio-net-pci, id \"net6\"\r\n
disable-legacy = \"off\"\r\n            disable-modern = false\r\n
       ioeventfd = true\r\n            vectors = 4 (0x4)\r\n
 virtio-pci-bus-master-bug-migration = false\r\n
migrate-extra = true\r\n            modern-pio-notify = false\r\n
      x-disable-pcie = false\r\n            page-per-vq = false\r\n
        x-ignore-backend-features = false\r\n            ats =
false\r\n            x-ats-page-aligned = true\r\n
x-pcie-deverr-init = true\r\n            x-pcie-lnkctl-init = true\r\n
           x-pcie-pm-init = true\r\n
x-pcie-pm-no-soft-reset = false\r\n            x-pcie-flr-init =
true\r\n            aer = false\r\n            addr = 06.0\r\n
   romfile = \"efi-virtio.rom\"\r\n            romsize = 262144
(0x40000)\r\n            rombar = 1 (0x1)\r\n            multifunction
= false\r\n            x-pcie-lnksta-dllla = true\r\n
x-pcie-extcap-init = true\r\n            failover_pair_id = \"\"\r\n
         acpi-index = 0 (0x0)\r\n            x-pcie-err-unc-mask =
true\r\n            x-pcie-ari-nextfn-1 = false\r\n
x-max-bounce-buffer-size = 4096 (4 KiB)\r\n            x-pcie-ext-tag
= false\r\n            busnr = 1 (0x1)\r\n            class Ethernet
controller, addr 01:06.0, pci id 1af4:1000 (sub 1af4:0001)\r\n
   bar 0: i/o at 0x6100 [0x611f]\r\n            bar 1: mem at
0x88401000 [0x88401fff]\r\n            bar 4: mem at 0x8000004000
[0x8000007fff]\r\n            bar 6: mem at 0xffffffffffffffff
[0x3fffe]\r\n            bus: virtio-bus\r\n              type
virtio-pci-bus\r\n              dev: virtio-net-device, id \"\"\r\n
            csum = true\r\n                guest_csum = true\r\n
         gso = true\r\n                guest_tso4 = true\r\n
     guest_tso6 = true\r\n                guest_ecn = true\r\n
       guest_ufo = true\r\n                guest_announce = true\r\n
             host_tso4 = true\r\n                host_tso6 = true\r\n
              host_ecn = true\r\n                host_ufo = true\r\n
             mrg_rxbuf = true\r\n                status = true\r\n
           ctrl_vq = true\r\n                ctrl_rx = true\r\n
        ctrl_vlan = true\r\n                ctrl_rx_extra = true\r\n
             ctrl_mac_addr = true\r\n
ctrl_guest_offloads = true\r\n                mq = false\r\n
     rss = false\r\n                hash = false\r\n
ebpf-rss-fds = <null>\r\n                guest_rsc_ext = false\r\n
           rsc_interval = 300000 (0x493e0)\r\n                mac =
\"02:01:51:df:1b:c5\"\r\n                netdev = \"hostnet6\"\r\n
           x-txtimer = 150000 (0x249f0)\r\n                x-txburst =
256 (0x100)\r\n                tx = \"\"\r\n
rx_queue_size = 256 (0x100)\r\n                tx_queue_size = 256
(0x100)\r\n                host_mtu = 0 (0x0)\r\n
x-mtu-bypass-backend = true\r\n                speed = -1
(0xffffffffffffffff)\r\n                duplex = \"\"\r\n
  failover = false\r\n                guest_uso4 = true\r\n
    guest_uso6 = true\r\n                host_uso = true\r\n
     indirect_desc = true\r\n                event_idx = true\r\n
          notify_on_empty = true\r\n                any_layout =
true\r\n                iommu_platform = false\r\n
packed = false\r\n                queue_reset = true\r\n
 in_order = false\r\n                use-started = true\r\n
    use-disabled-flag = true\r\n                x-disable-legacy-check
= false\r\n          dev: virtio-rng-pci, id \"\"\r\n
disable-legacy = \"off\"\r\n            disable-modern = false\r\n
       ioeventfd = true\r\n            vectors = 2 (0x2)\r\n
 virtio-pci-bus-master-bug-migration = false\r\n
migrate-extra = true\r\n            modern-pio-notify = false\r\n
      x-disable-pcie = false\r\n            page-per-vq = false\r\n
        x-ignore-backend-features = false\r\n            ats =
false\r\n            x-ats-page-aligned = true\r\n
x-pcie-deverr-init = true\r\n            x-pcie-lnkctl-init = true\r\n
           x-pcie-pm-init = true\r\n
x-pcie-pm-no-soft-reset = false\r\n            x-pcie-flr-init =
true\r\n            aer = false\r\n            addr = 03.0\r\n
   romfile = \"\"\r\n            romsize = 4294967295 (0xffffffff)\r\n
           rombar = 1 (0x1)\r\n            multifunction = false\r\n
         x-pcie-lnksta-dllla = true\r\n            x-pcie-extcap-init
= true\r\n            failover_pair_id = \"\"\r\n
acpi-index = 0 (0x0)\r\n            x-pcie-err-unc-mask = true\r\n
       x-pcie-ari-nextfn-1 = false\r\n
x-max-bounce-buffer-size = 4096 (4 KiB)\r\n            x-pcie-ext-tag
= false\r\n            busnr = 1 (0x1)\r\n            class Class
00ff, addr 01:03.0, pci id 1af4:1005 (sub 1af4:0004)\r\n
bar 0: i/o at 0x6120 [0x613f]\r\n            bar 1: mem at 0x88403000
[0x88403fff]\r\n            bar 4: mem at 0x800000c000
[0x800000ffff]\r\n            bus: virtio-bus\r\n              type
virtio-pci-bus\r\n              dev: virtio-rng-device, id \"\"\r\n
            max-bytes = 1024 (0x400)\r\n                period = 1000
(0x3e8)\r\n                indirect_desc = true\r\n
event_idx = true\r\n                notify_on_empty = true\r\n
       any_layout = true\r\n                iommu_platform = false\r\n
               packed = false\r\n                queue_reset =
true\r\n                in_order = false\r\n
use-started = true\r\n                use-disabled-flag = true\r\n
           x-disable-legacy-check = false\r\n      dev: qxl-vga, id
\"\"\r\n        ram_size = 67108864 (0x4000000)\r\n        vram_size =
67108864 (0x4000000)\r\n        revision = 5 (0x5)\r\n        debug =
0 (0x0)\r\n        guestdebug = 0 (0x0)\r\n        cmdlog = 0
(0x0)\r\n        ram_size_mb = 4294967295 (0xffffffff)\r\n
vram_size_mb = 4294967295 (0xffffffff)\r\n        vram64_size_mb =
4294967295 (0xffffffff)\r\n        vgamem_mb = 16 (0x10)\r\n
surfaces = 1024 (0x400)\r\n        max_outputs = 0 (0x0)\r\n
xres = 0 (0x0)\r\n        yres = 0 (0x0)\r\n        global-vmstate =
false\r\n        addr = 01.0\r\n        romfile =
\"vgabios-qxl.bin\"\r\n        romsize = 65536 (0x10000)\r\n
rombar = 1 (0x1)\r\n        multifunction = false\r\n
x-pcie-lnksta-dllla = true\r\n        x-pcie-extcap-init = true\r\n
    failover_pair_id = \"\"\r\n        acpi-index = 0 (0x0)\r\n
x-pcie-err-unc-mask = true\r\n        x-pcie-ari-nextfn-1 = false\r\n
      x-max-bounce-buffer-size = 4096 (4 KiB)\r\n
x-pcie-ext-tag = false\r\n        busnr = 0 (0x0)\r\n        class VGA
controller, addr 00:01.0, pci id 1b36:0100 (sub 1af4:1100)\r\n
bar 0: mem at 0x84000000 [0x87ffffff]\r\n        bar 1: mem at
0x80000000 [0x83ffffff]\r\n        bar 2: mem at 0x88640000
[0x88641fff]\r\n        bar 3: i/o at 0x70c0 [0x70df]\r\n        bar
6: mem at 0xffffffffffffffff [0xfffe]\r\n      dev: ICH9-SMB, id
\"\"\r\n        addr = 1f.3\r\n        romfile = \"\"\r\n
romsize = 4294967295 (0xffffffff)\r\n        rombar = 1 (0x1)\r\n
  multifunction = true\r\n        x-pcie-lnksta-dllla = true\r\n
 x-pcie-extcap-init = true\r\n        failover_pair_id = \"\"\r\n
  acpi-index = 0 (0x0)\r\n        x-pcie-err-unc-mask = true\r\n
 x-pcie-ari-nextfn-1 = false\r\n        x-max-bounce-buffer-size =
4096 (4 KiB)\r\n        x-pcie-ext-tag = false\r\n        busnr = 0
(0x0)\r\n        class SMBus, addr 00:1f.3, pci id 8086:2930 (sub
1af4:1100)\r\n        bar 4: i/o at 0x7000 [0x703f]\r\n        bus:
i2c\r\n          type i2c-bus\r\n          dev: smbus-eeprom, id
\"\"\r\n            address = 87 (0x57)\r\n          dev:
smbus-eeprom, id \"\"\r\n            address = 86 (0x56)\r\n
dev: smbus-eeprom, id \"\"\r\n            address = 85 (0x55)\r\n
    dev: smbus-eeprom, id \"\"\r\n            address = 84 (0x54)\r\n
        dev: smbus-eeprom, id \"\"\r\n            address = 83
(0x53)\r\n          dev: smbus-eeprom, id \"\"\r\n            address
= 82 (0x52)\r\n          dev: smbus-eeprom, id \"\"\r\n
address = 81 (0x51)\r\n          dev: smbus-eeprom, id \"\"\r\n
    address = 80 (0x50)\r\n      dev: ich9-usb-uhci3, id \"\"\r\n
  masterbus = \"usb-bus.0\"\r\n        firstport = 4 (0x4)\r\n
bandwidth = 1280 (0x500)\r\n        maxframes = 128 (0x80)\r\n
addr = 1d.2\r\n        romfile = \"\"\r\n        romsize = 4294967295
(0xffffffff)\r\n        rombar = 1 (0x1)\r\n        multifunction =
true\r\n        x-pcie-lnksta-dllla = true\r\n
x-pcie-extcap-init = true\r\n        failover_pair_id = \"\"\r\n
 acpi-index = 0 (0x0)\r\n        x-pcie-err-unc-mask = true\r\n
x-pcie-ari-nextfn-1 = false\r\n        x-max-bounce-buffer-size = 4096
(4 KiB)\r\n        x-pcie-ext-tag = false\r\n        busnr = 0
(0x0)\r\n        class USB controller, addr 00:1d.2, pci id 8086:2936
(sub 1af4:1100)\r\n        bar 4: i/o at 0x7060 [0x707f]\r\n      dev:
ich9-usb-uhci2, id \"\"\r\n        masterbus = \"usb-bus.0\"\r\n
 firstport = 2 (0x2)\r\n        bandwidth = 1280 (0x500)\r\n
maxframes = 128 (0x80)\r\n        addr = 1d.1\r\n        romfile =
\"\"\r\n        romsize = 4294967295 (0xffffffff)\r\n        rombar =
1 (0x1)\r\n        multifunction = true\r\n        x-pcie-lnksta-dllla
= true\r\n        x-pcie-extcap-init = true\r\n
failover_pair_id = \"\"\r\n        acpi-index = 0 (0x0)\r\n
x-pcie-err-unc-mask = true\r\n        x-pcie-ari-nextfn-1 = false\r\n
      x-max-bounce-buffer-size = 4096 (4 KiB)\r\n
x-pcie-ext-tag = false\r\n        busnr = 0 (0x0)\r\n        class USB
controller, addr 00:1d.1, pci id 8086:2935 (sub 1af4:1100)\r\n
bar 4: i/o at 0x7080 [0x709f]\r\n      dev: ich9-usb-uhci1, id
\"\"\r\n        masterbus = \"usb-bus.0\"\r\n        firstport = 0
(0x0)\r\n        bandwidth = 1280 (0x500)\r\n        maxframes = 128
(0x80)\r\n        addr = 1d.0\r\n        romfile = \"\"\r\n
romsize = 4294967295 (0xffffffff)\r\n        rombar = 1 (0x1)\r\n
  multifunction = true\r\n        x-pcie-lnksta-dllla = true\r\n
 x-pcie-extcap-init = true\r\n        failover_pair_id = \"\"\r\n
  acpi-index = 0 (0x0)\r\n        x-pcie-err-unc-mask = true\r\n
 x-pcie-ari-nextfn-1 = false\r\n        x-max-bounce-buffer-size =
4096 (4 KiB)\r\n        x-pcie-ext-tag = false\r\n        busnr = 0
(0x0)\r\n        class USB controller, addr 00:1d.0, pci id 8086:2934
(sub 1af4:1100)\r\n        bar 4: i/o at 0x70a0 [0x70bf]\r\n      dev:
ich9-usb-ehci1, id \"\"\r\n        maxframes = 128 (0x80)\r\n
addr = 1d.7\r\n        romfile = \"\"\r\n        romsize = 4294967295
(0xffffffff)\r\n        rombar = 1 (0x1)\r\n        multifunction =
true\r\n        x-pcie-lnksta-dllla = true\r\n
x-pcie-extcap-init = true\r\n        failover_pair_id = \"\"\r\n
 acpi-index = 0 (0x0)\r\n        x-pcie-err-unc-mask = true\r\n
x-pcie-ari-nextfn-1 = false\r\n        x-max-bounce-buffer-size = 4096
(4 KiB)\r\n        x-pcie-ext-tag = false\r\n        busnr = 0
(0x0)\r\n        class USB controller, addr 00:1d.7, pci id 8086:293a
(sub 1af4:1100)\r\n        bar 0: mem at 0x88643000 [0x88643fff]\r\n
     bus: usb-bus.0\r\n          type usb-bus\r\n          dev:
usb-tablet, id \"input0\"\r\n            usb_version = 2 (0x2)\r\n
       display = \"\"\r\n            head = 0 (0x0)\r\n
port = \"\"\r\n            serial = \"\"\r\n            msos-desc =
true\r\n            pcap = \"\"\r\n            addr 0.0, port 1, speed
480, name QEMU USB Tablet, attached\r\n      dev: ich9-ahci, id
\"\"\r\n        addr = 1f.2\r\n        romfile = \"\"\r\n
romsize = 4294967295 (0xffffffff)\r\n        rombar = 1 (0x1)\r\n
  multifunction = true\r\n        x-pcie-lnksta-dllla = true\r\n
 x-pcie-extcap-init = true\r\n        failover_pair_id = \"\"\r\n
  acpi-index = 0 (0x0)\r\n        x-pcie-err-unc-mask = true\r\n
 x-pcie-ari-nextfn-1 = false\r\n        x-max-bounce-buffer-size =
4096 (4 KiB)\r\n        x-pcie-ext-tag = false\r\n        busnr = 0
(0x0)\r\n        class SATA controller, addr 00:1f.2, pci id 8086:2922
(sub 1af4:1100)\r\n        bar 4: i/o at 0x7040 [0x705f]\r\n
bar 5: mem at 0x88642000 [0x88642fff]\r\n        bus: ide.5\r\n
  type IDE\r\n        bus: ide.4\r\n          type IDE\r\n        bus:
ide.3\r\n          type IDE\r\n        bus: ide.2\r\n          type
IDE\r\n        bus: ide.1\r\n          type IDE\r\n        bus:
ide.0\r\n          type IDE\r\n      dev: ICH9-LPC, id \"\"\r\n
gpio-out \"gsi\" 24\r\n        noreboot = false\r\n        smm-compat
= false\r\n        smm-enabled = true\r\n        x-smi-broadcast =
true\r\n        x-smi-cpu-hotplug = true\r\n
x-smi-cpu-hotunplug = true\r\n        x-smi-swsmi-timer = false\r\n
    x-smi-periodic-timer = false\r\n        addr = 1f.0\r\n
romfile = \"\"\r\n        romsize = 4294967295 (0xffffffff)\r\n
rombar = 1 (0x1)\r\n        multifunction = true\r\n
x-pcie-lnksta-dllla = true\r\n        x-pcie-extcap-init = true\r\n
    failover_pair_id = \"\"\r\n        acpi-index = 0 (0x0)\r\n
x-pcie-err-unc-mask = true\r\n        x-pcie-ari-nextfn-1 = false\r\n
      x-max-bounce-buffer-size = 4096 (4 KiB)\r\n
x-pcie-ext-tag = false\r\n        busnr = 0 (0x0)\r\n        class ISA
bridge, addr 00:1f.0, pci id 8086:2918 (sub 1af4:1100)\r\n        bus:
isa.0\r\n          type ISA\r\n          dev: isa-serial, id
\"serial0\"\r\n            index = 0 (0x0)\r\n            iobase =
1016 (0x3f8)\r\n            irq = 4 (0x4)\r\n          dev: pvpanic,
id \"\"\r\n            ioport = 1285 (0x505)\r\n            events = 7
(0x7)\r\n          dev: port92, id \"\"\r\n            gpio-out
\"a20\" 1\r\n          dev: vmmouse, id \"\"\r\n          dev: vmport,
id \"\"\r\n            x-read-set-eax = true\r\n
x-signal-unsupported-cmd = true\r\n            x-report-vmx-type =
true\r\n            x-cmds-v2 = true\r\n            vmware-vmx-version
= 6 (0x6)\r\n            vmware-vmx-type = 2 (0x2)\r\n          dev:
i8042, id \"\"\r\n            gpio-in \"ps2-mouse-input-irq\" 1\r\n
        gpio-in \"ps2-kbd-input-irq\" 1\r\n            gpio-out \"\"
2\r\n            gpio-out \"a20\" 1\r\n            extended-state =
true\r\n            kbd-throttle = false\r\n            kbd-irq = 1
(0x1)\r\n            mouse-irq = 12 (0xc)\r\n          dev: isa-pcspk,
id \"\"\r\n            audiodev = \"\"\r\n            iobase = 97
(0x61)\r\n            migrate = true\r\n          dev: isa-pit, id
\"\"\r\n            gpio-in \"\" 1\r\n            gpio-out \"\" 1\r\n
          iobase = 64 (0x40)\r\n          dev: isa-i8259, id \"\"\r\n
          gpio-in \"\" 8\r\n            gpio-out \"\" 1\r\n
iobase = 160 (0xa0)\r\n            elcr_addr = 1233 (0x4d1)\r\n
    elcr_mask = 222 (0xde)\r\n            master = false\r\n
dev: isa-i8259, id \"\"\r\n            gpio-in \"\" 8\r\n
gpio-out \"\" 1\r\n            iobase = 32 (0x20)\r\n
elcr_addr = 1232 (0x4d0)\r\n            elcr_mask = 248 (0xf8)\r\n
       master = true\r\n          dev: mc146818rtc, id \"\"\r\n
    gpio-out \"\" 1\r\n            base_year = 0 (0x0)\r\n
iobase = 112 (0x70)\r\n            irq = 8 (0x8)\r\n
lost_tick_policy = \"discard\"\r\n          dev: i8257, id \"\"\r\n
        base = 192 (0xc0)\r\n            page-base = 136 (0x88)\r\n
        pageh-base = -1 (0xffffffffffffffff)\r\n            dshift = 1
(0x1)\r\n          dev: i8257, id \"\"\r\n            base = 0
(0x0)\r\n            page-base = 128 (0x80)\r\n            pageh-base
= -1 (0xffffffffffffffff)\r\n            dshift = 0 (0x0)\r\n
dev: mch, id \"\"\r\n        extended-tseg-mbytes = 16 (0x10)\r\n
  smbase-smram = true\r\n        addr = 00.0\r\n        romfile =
\"\"\r\n        romsize = 4294967295 (0xffffffff)\r\n        rombar =
1 (0x1)\r\n        multifunction = false\r\n
x-pcie-lnksta-dllla = true\r\n        x-pcie-extcap-init = true\r\n
    failover_pair_id = \"\"\r\n        acpi-index = 0 (0x0)\r\n
x-pcie-err-unc-mask = true\r\n        x-pcie-ari-nextfn-1 = false\r\n
      x-max-bounce-buffer-size = 4096 (4 KiB)\r\n
x-pcie-ext-tag = false\r\n        busnr = 0 (0x0)\r\n        class
Host bridge, addr 00:00.0, pci id 8086:29c0 (sub 1af4:1100)\r\n  dev:
fw_cfg_io, id \"\"\r\n    dma_enabled = true\r\n    x-file-slots = 32
(0x20)\r\n    acpi-mr-restore = true\r\n  dev: kvmclock, id \"\"\r\n
 x-mach-use-reliable-get-clock = true\r\n  dev: kvmvapic, id
\"\"\r\n"}


> 2) whether the migration with if you disabled those features explicitly in 9.2.4
Could you tell me, how to disable these features?
I tried this change on both source  and target qemu, but still see the
same error, althrough info virtio-status no longer report these
features.
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -3984,11 +3984,11 @@ static Property virtio_net_properties[] = {
     DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
     DEFINE_PROP_BOOL("failover", VirtIONet, failover, false),
     DEFINE_PROP_BIT64("guest_uso4", VirtIONet, host_features,
-                      VIRTIO_NET_F_GUEST_USO4, true),
+                      VIRTIO_NET_F_GUEST_USO4, false),
     DEFINE_PROP_BIT64("guest_uso6", VirtIONet, host_features,
-                      VIRTIO_NET_F_GUEST_USO6, true),
+                      VIRTIO_NET_F_GUEST_USO6, false),
     DEFINE_PROP_BIT64("host_uso", VirtIONet, host_features,
-                      VIRTIO_NET_F_HOST_USO, true),
+                      VIRTIO_NET_F_HOST_USO, false),
     DEFINE_PROP_END_OF_LIST(),
 };


>
> > Or should QEMU handle such feature mismatches more gracefully (e.g.,
> > automatically disable unsupported virtio features during migration)?
>
> This would break guests as it could be noticed by guests.
understood.
>
> >
> > Any guidance on how to make migration between these versions work
> > would be appreciated.
> >
> > ________________________________
> >
> > Thanks,
> > Jinpu Wang @ IONOS Cloud
> >
>
> Thanks
>

Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Peter Xu]

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,

-- 
Peter Xu

Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Jason Wang]

x

On Thu, Nov 6, 2025 at 6:17 AM Peter Xu <peterx@redhat.com> 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);
+        }
     }

So qemu would fail earlier than fail the migration.

Thanks


>
> --
> Peter Xu
>

Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Jinpu Wang]

Hi Jason,

On Thu, Nov 6, 2025 at 5:05 AM Jason Wang <jasowang@redhat.com> wrote:
>
> x
>
> On Thu, Nov 6, 2025 at 6:17 AM Peter Xu <peterx@redhat.com> 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,
is it the migration target or host kernel?
> So qemu would fail earlier than fail the migration.
>
> Thanks

Thx!
>
>
> >
> > --
> > Peter Xu
> >
>

Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Jason Wang]

On Thu, Nov 6, 2025 at 10:33 PM Jinpu Wang <jinpu.wang@ionos.com> wrote:
>
> Hi Jason,
>
> On Thu, Nov 6, 2025 at 5:05 AM Jason Wang <jasowang@redhat.com> wrote:
> >
> > x
> >
> > On Thu, Nov 6, 2025 at 6:17 AM Peter Xu <peterx@redhat.com> 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
> > >
> >
>

Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Jinpu Wang]

Hi Peter,
On Wed, Nov 5, 2025 at 11:17 PM Peter Xu <peterx@redhat.com> 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).
I feel this is the approach we should have picked.
>
> See:
>
> https://lore.kernel.org/all/ZqQNKZ9_OPhDq2AK@x1n/
Is there any effort to allow migration from new OS support the USO
features to old OS doesn't support it?
Any hint to make it work?
>
> Thanks,
>
> --
> Peter Xu
>
Thx for the help.

Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Jason Wang]

On Thu, Nov 6, 2025 at 10:28 PM Jinpu Wang <jinpu.wang@ionos.com> wrote:
>
> Hi Peter,
> On Wed, Nov 5, 2025 at 11:17 PM Peter Xu <peterx@redhat.com> 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).
> I feel this is the approach we should have picked.
> >
> > See:
> >
> > https://lore.kernel.org/all/ZqQNKZ9_OPhDq2AK@x1n/
> Is there any effort to allow migration from new OS support the USO
> features to old OS doesn't support it?

You can teach your management to disable USO via the qemu command line.

> Any hint to make it work?

Thanks

> >
> > Thanks,
> >
> > --
> > Peter Xu
> >
> Thx for the help.
>

Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Jinpu Wang]

Hi Jason,

On Fri, Nov 7, 2025 at 2:02 AM Jason Wang <jasowang@redhat.com> wrote:
>
> On Thu, Nov 6, 2025 at 10:28 PM Jinpu Wang <jinpu.wang@ionos.com> wrote:
> >
> > Hi Peter,
> > On Wed, Nov 5, 2025 at 11:17 PM Peter Xu <peterx@redhat.com> 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).
> > I feel this is the approach we should have picked.
> > >
> > > See:
> > >
> > > https://lore.kernel.org/all/ZqQNKZ9_OPhDq2AK@x1n/
> > Is there any effort to allow migration from new OS support the USO
> > features to old OS doesn't support it?
>
> You can teach your management to disable USO via the qemu command line.

I added "host_uso=false,guest_uso4=false,guest_uso6=false" for -device
virtio-net-pci
But migration still fails with slightly different error:
char device redirected to /dev/pts/1 (label charserial0)
2025-11-07T15:00:45.528098Z qemu-8.2: Features 0x10130afffa7
unsupported. Allowed features: 0x179bfffe7
2025-11-07T15:00:45.528245Z qemu-8.2: Failed to load virtio-net:virtio
2025-11-07T15:00:45.528253Z qemu-8.2: error while loading state for
instance 0x0 of device '0000:00:02.0:06.0/virtio-net'

I suppose it is VIRTIO_F_RING_RESET?
Any idea? I didn't find option to disable it
>
> > Any hint to make it work?
>
> Thanks

Thx!
>
> > >
> > > Thanks,
> > >
> > > --
> > > Peter Xu
> > >
> > Thx for the help.
> >
>

Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Jinpu Wang]

On Fri, Nov 7, 2025 at 4:06 PM Jinpu Wang <jinpu.wang@ionos.com> wrote:
>
> Hi Jason,
>
> On Fri, Nov 7, 2025 at 2:02 AM Jason Wang <jasowang@redhat.com> wrote:
> >
> > On Thu, Nov 6, 2025 at 10:28 PM Jinpu Wang <jinpu.wang@ionos.com> wrote:
> > >
> > > Hi Peter,
> > > On Wed, Nov 5, 2025 at 11:17 PM Peter Xu <peterx@redhat.com> 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).
> > > I feel this is the approach we should have picked.
> > > >
> > > > See:
> > > >
> > > > https://lore.kernel.org/all/ZqQNKZ9_OPhDq2AK@x1n/
> > > Is there any effort to allow migration from new OS support the USO
> > > features to old OS doesn't support it?
> >
> > You can teach your management to disable USO via the qemu command line.
>
> I added "host_uso=false,guest_uso4=false,guest_uso6=false" for -device
> virtio-net-pci
> But migration still fails with slightly different error:
> char device redirected to /dev/pts/1 (label charserial0)
> 2025-11-07T15:00:45.528098Z qemu-8.2: Features 0x10130afffa7
> unsupported. Allowed features: 0x179bfffe7
> 2025-11-07T15:00:45.528245Z qemu-8.2: Failed to load virtio-net:virtio
> 2025-11-07T15:00:45.528253Z qemu-8.2: error while loading state for
> instance 0x0 of device '0000:00:02.0:06.0/virtio-net'
>
> I suppose it is VIRTIO_F_RING_RESET?
> Any idea? I didn't find option to disable it
Found it,  "host_uso=false,guest_uso4=false,guest_uso6=false,queue_reset=false"
is needed to allow migration from new OS to old OS
> >
> > > Any hint to make it work?
> >
> > Thanks
>
> Thx!
> >
> > > >
> > > > Thanks,
> > > >
> > > > --
> > > > Peter Xu
> > > >
> > > Thx for the help.
> > >
> >

Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)

[Michael Tokarev]

On 11/5/25 11:49, Jinpu Wang wrote:
> Hello QEMU developers,
> 
> I’m encountering a migration failure when trying to live-migrate a VM
> from a newer host (kernel 6.12 + QEMU 9.2.4) to an older one (kernel
> 6.1 + QEMU 8.2.10).

This is just to note - both 9.2.x and 8.2.x series are end-of-line now
from the qemu PoV, there are no further releases planned.

It'd be nice to find out what's going on here anyway.  Maybe you can
patch this on your side.

Thanks,

/mjt