Lines Matching full:for

33 except for a few cases where the backend features influence frontend
34 device feature exposure.  But that is not relevant for this section.
47   Exactly the same case than the previous one, but for 5.1.
55 the latest machine type for that version (pc-5.2) but one of an older
102 qemu-5.2 has to expect that it is not going to get data for the new
110 that array to see what value it needs to get for that feature.  And
113 To create a property for a device, we need to use one of the
115 macros that exist.  With it, we set the default value for that
117 version.  But if we want a different value for a previous version, we
135 put the extra information for the other 3 queues, and we fail
139 to qemu-5.2, we only sent information for one queue, but destination
145 for virtio-blk-devices to 1.
199 The relevant parts for migration are::
210 It changes the default value of num_queues.  But it fishes it for old
245 You can read the documentation for QEMU x86 cpu models here:
250 newest cpu model that is supported for all cpus.
305 Notice that we don't recommend to use -cpu host for migration.  It is
320 We broke migration for old machine types continuously during
359 The relevant bits of the commit for our example are this ones::
375 The patch changes how we configure PCI space for AER.  But QEMU fails
385     hw/pci: Disable PCI_ERR_UNCOR_MASK register for machine type < 8.0
391 First, we create a new property for the device to be able to configure
406 Notice that we enable the feature for new machine types.
435 I.e. If the property bit is enabled, we configure it as we did for
438 And now, everything that is missing is disabling the feature for old
472 different.  For the 1st set, their fail and we can do nothing, both
505 property for pc-7.2.  Notice that we need to remember, it is not