* [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
@ 2025-11-05 8:49 Jinpu Wang
2025-11-05 8:59 ` Jason Wang
2025-11-05 9:14 ` Michael Tokarev
0 siblings, 2 replies; 12+ messages in thread
From: Jinpu Wang @ 2025-11-05 8:49 UTC (permalink / raw)
To: qemu-devel, Peter Xu, qemu-stable, Jason Wang, Fabiano Rosas,
Yu Zhang
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
2025-11-05 8:49 [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
@ 2025-11-05 8:59 ` Jason Wang
2025-11-05 9:27 ` Jinpu Wang
2025-11-05 9:14 ` Michael Tokarev
1 sibling, 1 reply; 12+ messages in thread
From: Jason Wang @ 2025-11-05 8:59 UTC (permalink / raw)
To: Jinpu Wang; +Cc: qemu-devel, Peter Xu, qemu-stable, Fabiano Rosas, Yu Zhang
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
2025-11-05 8:49 [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
2025-11-05 8:59 ` Jason Wang
@ 2025-11-05 9:14 ` Michael Tokarev
1 sibling, 0 replies; 12+ messages in thread
From: Michael Tokarev @ 2025-11-05 9:14 UTC (permalink / raw)
To: Jinpu Wang, qemu-devel, Peter Xu, qemu-stable, Jason Wang,
Fabiano Rosas, Yu Zhang, qemu-stable
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
2025-11-05 8:59 ` Jason Wang
@ 2025-11-05 9:27 ` Jinpu Wang
2025-11-05 22:17 ` Peter Xu
0 siblings, 1 reply; 12+ messages in thread
From: Jinpu Wang @ 2025-11-05 9:27 UTC (permalink / raw)
To: Jason Wang; +Cc: qemu-devel, Peter Xu, qemu-stable, Fabiano Rosas, Yu Zhang
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
2025-11-05 9:27 ` Jinpu Wang
@ 2025-11-05 22:17 ` Peter Xu
2025-11-06 4:05 ` Jason Wang
2025-11-06 14:28 ` Jinpu Wang
0 siblings, 2 replies; 12+ messages in thread
From: Peter Xu @ 2025-11-05 22:17 UTC (permalink / raw)
To: Jinpu Wang; +Cc: Jason Wang, qemu-devel, qemu-stable, Fabiano Rosas, Yu Zhang
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
2025-11-05 22:17 ` Peter Xu
@ 2025-11-06 4:05 ` Jason Wang
2025-11-06 14:32 ` Jinpu Wang
2025-11-06 14:28 ` Jinpu Wang
1 sibling, 1 reply; 12+ messages in thread
From: Jason Wang @ 2025-11-06 4:05 UTC (permalink / raw)
To: Peter Xu; +Cc: Jinpu Wang, qemu-devel, qemu-stable, Fabiano Rosas, Yu Zhang
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
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
2025-11-05 22:17 ` Peter Xu
2025-11-06 4:05 ` Jason Wang
@ 2025-11-06 14:28 ` Jinpu Wang
2025-11-07 1:02 ` Jason Wang
1 sibling, 1 reply; 12+ messages in thread
From: Jinpu Wang @ 2025-11-06 14:28 UTC (permalink / raw)
To: Peter Xu; +Cc: Jason Wang, qemu-devel, qemu-stable, Fabiano Rosas, Yu Zhang
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
2025-11-06 4:05 ` Jason Wang
@ 2025-11-06 14:32 ` Jinpu Wang
2025-11-07 1:03 ` Jason Wang
0 siblings, 1 reply; 12+ messages in thread
From: Jinpu Wang @ 2025-11-06 14:32 UTC (permalink / raw)
To: Jason Wang; +Cc: Peter Xu, qemu-devel, qemu-stable, Fabiano Rosas, Yu Zhang
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
> >
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
2025-11-06 14:28 ` Jinpu Wang
@ 2025-11-07 1:02 ` Jason Wang
2025-11-07 15:06 ` Jinpu Wang
0 siblings, 1 reply; 12+ messages in thread
From: Jason Wang @ 2025-11-07 1:02 UTC (permalink / raw)
To: Jinpu Wang; +Cc: Peter Xu, qemu-devel, qemu-stable, Fabiano Rosas, Yu Zhang
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.
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
2025-11-06 14:32 ` Jinpu Wang
@ 2025-11-07 1:03 ` Jason Wang
0 siblings, 0 replies; 12+ messages in thread
From: Jason Wang @ 2025-11-07 1:03 UTC (permalink / raw)
To: Jinpu Wang; +Cc: Peter Xu, qemu-devel, qemu-stable, Fabiano Rosas, Yu Zhang
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
> > >
> >
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
2025-11-07 1:02 ` Jason Wang
@ 2025-11-07 15:06 ` Jinpu Wang
2025-11-07 16:11 ` Jinpu Wang
0 siblings, 1 reply; 12+ messages in thread
From: Jinpu Wang @ 2025-11-07 15:06 UTC (permalink / raw)
To: Jason Wang; +Cc: Peter Xu, qemu-devel, qemu-stable, Fabiano Rosas, Yu Zhang
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.
> >
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BUG] Migration failure between QEMU 9.2.4 → 8.2.10 due to virtio-net feature mismatch (VIRTIO_F_RING_RESET / USO features)
2025-11-07 15:06 ` Jinpu Wang
@ 2025-11-07 16:11 ` Jinpu Wang
0 siblings, 0 replies; 12+ messages in thread
From: Jinpu Wang @ 2025-11-07 16:11 UTC (permalink / raw)
To: Jason Wang; +Cc: Peter Xu, qemu-devel, qemu-stable, Fabiano Rosas, Yu Zhang
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.
> > >
> >
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2025-11-07 16:12 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-11-05 8:49 [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
2025-11-05 8:59 ` Jason Wang
2025-11-05 9:27 ` Jinpu Wang
2025-11-05 22:17 ` Peter Xu
2025-11-06 4:05 ` Jason Wang
2025-11-06 14:32 ` Jinpu Wang
2025-11-07 1:03 ` Jason Wang
2025-11-06 14:28 ` Jinpu Wang
2025-11-07 1:02 ` Jason Wang
2025-11-07 15:06 ` Jinpu Wang
2025-11-07 16:11 ` Jinpu Wang
2025-11-05 9:14 ` Michael Tokarev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).