Lines Matching +full:qemu +full:- +full:x86_64

5 ---------------------------------
7 When we do migration, we have two QEMU processes: the source and the
15 - QEMU version
16 - machine type version
20 - qemu-system-x86_64 (v5.2), from now on qemu-5.2.
21 - qemu-system-x86_64 (v5.1), from now on qemu-5.1.
26 - pc-q35-5.2 (newer one in qemu-5.2) from now on pc-5.2
27 - pc-q35-5.1 (newer one in qemu-5.1) from now on pc-5.1
30 machine type in both source and destination. The QEMU hardware
37 start with the trivial ones, QEMU is the same on source and
40 1 - qemu-5.2 -M pc-5.2 -> migrates to -> qemu-5.2 -M pc-5.2
42 This is the latest QEMU with the latest machine type.
45 2 - qemu-5.1 -M pc-5.1 -> migrates to -> qemu-5.1 -M pc-5.1
54 we have the same QEMU version in both sides (qemu-5.2) but we are using
55 the latest machine type for that version (pc-5.2) but one of an older
56 QEMU version, in this case pc-5.1.
58 3 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
60 It needs to use the definition of pc-5.1 and the devices as they
62 both sides are the same QEMU and both sides have exactly the same
63 idea of what the pc-5.1 machine is.
65 4 - qemu-5.1 -M pc-5.2 -> migrates to -> qemu-5.1 -M pc-5.2
67 This combination is not possible as the qemu-5.1 doesn't understand
68 pc-5.2 machine type. So nothing to worry here.
70 Now it comes the interesting ones, when both QEMU processes are
71 different. Notice also that the machine type needs to be pc-5.1,
72 because we have the limitation than qemu-5.1 doesn't know pc-5.2. So
75 5 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.1 -M pc-5.1
79 migration to qemu-5.1. Notice that we can't make updates to
80 qemu-5.1 to understand whatever qemu-5.2 decides to change, so it is
81 in qemu-5.2 side to make the relevant changes.
83 6 - qemu-5.1 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
86 than we are able to receive migrations from qemu-5.1. The problem is
89 If qemu-5.1 and qemu-5.2 were the same, there will not be any
90 compatibility problems. But the reason that we create qemu-5.2 is to
94 we have a problem when we try to migrate between different QEMU
97 So we need a way to tell qemu-5.2 that when we are using machine type
98 pc-5.1, it needs to **not** use the feature, to be able to migrate to
99 real qemu-5.1.
101 And the equivalent part when migrating from qemu-5.1 to qemu-5.2.
102 qemu-5.2 has to expect that it is not going to get data for the new
103 feature, because qemu-5.1 doesn't know about it.
105 How do we tell QEMU about these device feature changes? In
114 DEFINE_PROP_*() macros. See include/hw/qdev-properties.h to find the
122 - name_device
123 - name_property
124 - value
128 In qemu-5.2 virtio-blk-device got multi queue support. This is a
129 change that is not backward compatible. In qemu-5.1 it has one
130 queue. In qemu-5.2 it has the same number of queues as the number of
138 Similar problem when we migrate from qemu-5.1 that has only one queue
139 to qemu-5.2, we only sent information for one queue, but destination
143 So, how can we address this problem. Easy, just convince qemu-5.2
144 that when it is running pc-5.1, it needs to set the number of queues
145 for virtio-blk-devices to 1.
149 5 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.1 -M pc-5.1
151 qemu-5.2 -M pc-5.1 sets number of queues to be 1.
152 qemu-5.1 -M pc-5.1 expects number of queues to be 1.
156 6 - qemu-5.1 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
158 qemu-5.1 -M pc-5.1 sets number of queues to be 1.
159 qemu-5.2 -M pc-5.1 expects number of queues to be 1.
165 3 - qemu-5.2 -M pc-5.1 -> migrates to -> qemu-5.2 -M pc-5.1
167 Here we have the same QEMU in both sides. So it doesn't matter a
175 A -> migrates -> B -> migrates -> C
179 A: qemu-5.1 -M pc-5.1
180 B: qemu-5.2 -M pc-5.1
181 C: qemu-5.2 -M pc-5.1
183 migration A -> B is case 6, so number of queues needs to be 1.
185 migration B -> C is case 3, so we don't care. But actually we
186 care because we haven't started the guest in qemu-5.2, it came
187 migrated from qemu-5.1. So to be in the safe place, we need to
188 always use number of queues 1 when we are using pc-5.1.
197 virtio-blk-pci: default num_queues to -smp N
201 @@ -1281,7 +1284,8 @@ static Property virtio_blk_properties[] = {
203 DEFINE_PROP_BIT("request-merging", VirtIOBlock, conf.request_merging, 0,
205 - DEFINE_PROP_UINT16("num-queues", VirtIOBlock, conf.num_queues, 1),
206 + DEFINE_PROP_UINT16("num-queues", VirtIOBlock, conf.num_queues,
208 DEFINE_PROP_UINT16("queue-size", VirtIOBlock, conf.queue_size, 256),
213 @@ -31,6 +31,7 @@
216 + { "virtio-blk-device", "num-queues", "1"},
221 ----------------------------------------------
223 Let's assume that we are using the same QEMU binary on both sides,
234 QEMU.
236 Notice that this is not completely related to QEMU. The most
238 application that launches QEMU. If QEMU is configured correctly, the
245 You can read the documentation for QEMU x86 cpu models here:
247 https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html
270 $ qemu-system-x86_64 -cpu host
274 $ qemu-system-x86_64 -cpu host
281 So, forgetting about cpu models and continuing with the -cpu host
285 Features: 'pcid' 'stibp' 'taa-no'
289 And we want to migrate between them, the way configure both QEMU cpu
294 $ qemu-system-x86_64 -cpu host,pcid=off,stibp=off
298 $ qemu-system-x86_64 -cpu host,taa-no=off
302 configuration is correct. QEMU doesn't know how to look at this kind
305 Notice that we don't recommend to use -cpu host for migration. It is
312 In this section we have considered that we are using the same QEMU
313 binary in both sides of the migration. If we use different QEMU
318 -----------------------------------------------------------
327 After the release of qemu-8.0 we found a problem when doing migration
328 of the machine type pc-7.2.
330 - $ qemu-7.2 -M pc-7.2 -> qemu-7.2 -M pc-7.2
334 - $ qemu-8.0 -M pc-7.2 -> qemu-8.0 -M pc-7.2
338 - $ qemu-8.0 -M pc-7.2 -> qemu-7.2 -M pc-7.2
342 - $ qemu-7.2 -M pc-7.2 -> qemu-8.0 -M pc-7.2
346 So clearly something fails when migration between qemu-7.2 and
347 qemu-8.0 with machine type pc-7.2. The error messages, and git bisect
350 In qemu-8.0 we got this commit::
361 --- a/hw/pci/pcie_aer.c
363 @@ -112,6 +112,10 @@ int pcie_aer_init(PCIDevice *dev,
365 pci_set_long(dev->w1cmask + offset + PCI_ERR_UNCOR_STATUS,
367 + pci_set_long(dev->config + offset + PCI_ERR_UNCOR_MASK,
369 + pci_set_long(dev->wmask + offset + PCI_ERR_UNCOR_MASK,
372 pci_set_long(dev->config + offset + PCI_ERR_UNCOR_SEVER,
375 The patch changes how we configure PCI space for AER. But QEMU fails
383 Date: Tue May 2 21:27:02 2023 -0300
389 The relevant parts of the fix in QEMU are as follow:
394 diff --git a/hw/pci/pci.c b/hw/pci/pci.c
396 --- a/hw/pci/pci.c
398 @@ -79,6 +79,8 @@ static Property pci_props[] = {
401 DEFINE_PROP_UINT32("acpi-index", PCIDevice, acpi_index, 0),
402 + DEFINE_PROP_BIT("x-pcie-err-unc-mask", PCIDevice, cap_present,
412 diff --git a/hw/pci/pcie_aer.c b/hw/pci/pcie_aer.c
414 --- a/hw/pci/pcie_aer.c
416 @@ -112,10 +112,13 @@ int pcie_aer_init(PCIDevice *dev, uint8_t cap_ver,
419 pci_set_long(dev->w1cmask + offset + PCI_ERR_UNCOR_STATUS,
421 - pci_set_long(dev->config + offset + PCI_ERR_UNCOR_MASK,
422 - PCI_ERR_UNC_MASK_DEFAULT);
423 - pci_set_long(dev->wmask + offset + PCI_ERR_UNCOR_MASK,
424 - PCI_ERR_UNC_SUPPORTED);
426 + if (dev->cap_present & QEMU_PCIE_ERR_UNC_MASK) {
427 + pci_set_long(dev->config + offset + PCI_ERR_UNCOR_MASK,
429 + pci_set_long(dev->wmask + offset + PCI_ERR_UNCOR_MASK,
433 pci_set_long(dev->config + offset + PCI_ERR_UNCOR_SEVER,
437 qemu-8.0. If the property bit is not set, we configure it as it was in 7.2.
442 diff --git a/hw/core/machine.c b/hw/core/machine.c
444 --- a/hw/core/machine.c
446 @@ -48,6 +48,7 @@ GlobalProperty hw_compat_7_2[] = {
447 { "e1000e", "migrate-timadj", "off" },
448 { "virtio-mem", "x-early-migration", "false" },
449 { "migration", "x-preempt-pre-7-2", "true" },
450 + { TYPE_PCI_DEVICE, "x-pcie-err-unc-mask", "off" },
454 And now, when qemu-8.0.1 is released with this fix, all combinations
457 - $ qemu-7.2 -M pc-7.2 -> qemu-7.2 -M pc-7.2 (works)
458 - $ qemu-8.0.1 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2 (works)
459 - $ qemu-8.0.1 -M pc-7.2 -> qemu-7.2 -M pc-7.2 (works)
460 - $ qemu-7.2 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2 (works)
468 - $ qemu-7.2 -M pc-7.2 -> qemu-7.2 -M pc-7.2
469 - $ qemu-8.0 -M pc-7.2 -> qemu-8.0 -M pc-7.2
470 - $ qemu-8.0.1 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
472 Now the interesting ones. When the QEMU processes versions are
476 - $ qemu-7.2 -M pc-7.2 -> qemu-8.0 -M pc-7.2
477 - $ qemu-8.0 -M pc-7.2 -> qemu-7.2 -M pc-7.2
480 change in qemu-8.0.1 release was to fix this issue:
482 - $ qemu-7.2 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
483 - $ qemu-8.0.1 -M pc-7.2 -> qemu-7.2 -M pc-7.2
485 But now we found that qemu-8.0 neither can migrate to qemu-7.2 not
486 qemu-8.0.1.
488 - $ qemu-8.0 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
489 - $ qemu-8.0.1 -M pc-7.2 -> qemu-8.0 -M pc-7.2
491 So, if we start a pc-7.2 machine in qemu-8.0 we can't migrate it to
492 anything except to qemu-8.0.
498 - $ qemu-8.0 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2
502 --device...,x-pci-e-err-unc-mask=on
506 property for pc-7.2. Notice that we need to remember, it is not
507 enough to know that the source of the migration is qemu-8.0. Think of
510 $ qemu-8.0 -M pc-7.2 -> qemu-8.0.1 -M pc-7.2 -> qemu-8.2 -M pc-7.2
512 In the second migration, the source is not qemu-8.0, but we still have
515 rebooted. But it is not a normal reboot (that don't reload QEMU) we
516 need the machine to poweroff/poweron on a fixed QEMU. And from now