Lines Matching full:that
12 There are two things that are different, but they have very similar
34 device feature exposure. But that is not relevant for this section.
36 I am going to list the number of combinations that we can have. Let's
55 the latest machine type for that version (pc-5.2) but one of an older
61 were configured on 5.1, but this should be easy in the sense that
71 different. Notice also that the machine type needs to be pc-5.1,
79 migration to qemu-5.1. Notice that we can't make updates to
90 compatibility problems. But the reason that we create qemu-5.2 is to
93 If we get a device that has a new feature, or change a default value,
97 So we need a way to tell qemu-5.2 that when we are using machine type
102 qemu-5.2 has to expect that it is not going to get data for the new
109 that array. And the device, during initialization needs to look at
110 that array to see what value it needs to get for that feature. And
111 what are we going to put in that array, the value of a property.
115 macros that exist. With it, we set the default value for that
116 property, and that is what it is going to get in the latest released
118 can change that in the hw_compat_X_Y arrays.
120 hw_compat_X_Y is an array of registers that have the format:
129 change that is not backward compatible. In qemu-5.1 it has one
133 When we are doing migration, if we migrate from a device that has 4
134 queues to a device that have only one queue, we don't know where to
138 Similar problem when we migrate from qemu-5.1 that has only one queue
140 has 4, and we have 3 queues that are not properly initialized and
144 that when it is running pc-5.1, it needs to set the number of queues
147 That way we fix the cases 5 and 6.
223 Let's assume that we are using the same QEMU binary on both sides,
224 just to make the things easier. But we have a device that has
225 different features on both sides of the migration. That can be
229 How can we get this to work with migration. The way to do that is
230 "theoretically" easy. You have to get the features that the device
231 has in the source of the migration. The features that the device has
233 features of both sides, and that is the way that you should launch
236 Notice that this is not completely related to QEMU. The most
237 important thing here is that this should be handled by the managing
238 application that launches QEMU. If QEMU is configured correctly, the
241 That said, actually doing it is complicated. Almost all devices are
249 See when they talk about migration they recommend that one chooses the
250 newest cpu model that is supported for all cpus.
252 Let's say that we have:
264 destination, it will find that the hardware is not there.
282 example, let's see that the differences of the cpus is that Host A and
301 of the management application or of the user to make sure that the
305 Notice that we don't recommend to use -cpu host for migration. It is
309 want to be able to migrate between hosts that show different features,
312 In this section we have considered that we are using the same QEMU
321 development. But as soon as we find that there is a problem, we fix
323 release that something has gone wrong.
406 Notice that we enable the feature for new machine types.
438 And now, everything that is missing is disabling the feature for old
478 This two are the ones that work. The whole point of making the
484 But now we found that qemu-8.0 neither can migrate to qemu-7.2 not
495 Yeap. If we know that we are going to do this migration:
504 do that migration to new machine types if we remember to enable that
505 property for pc-7.2. Notice that we need to remember, it is not
506 enough to know that the source of the migration is qemu-8.0. Think of
512 that "problem" and have that property enabled. Notice that we need to
514 rebooted. But it is not a normal reboot (that don't reload QEMU) we