1.. _Deprecated features: 2 3Deprecated features 4=================== 5 6In general features are intended to be supported indefinitely once 7introduced into QEMU. In the event that a feature needs to be removed, 8it will be listed in this section. The feature will remain functional for the 9release in which it was deprecated and one further release. After these two 10releases, the feature is liable to be removed. Deprecated features may also 11generate warnings on the console when QEMU starts up, or if activated via a 12monitor command, however, this is not a mandatory requirement. 13 14As a special exception to this general timeframe, rather than have an 15indefinite lifetime, versioned machine types are only intended to be 16supported for a period of 6 years, equivalent to 18 QEMU releases. All 17versioned machine types will be automatically marked deprecated after an 18initial 3 years (9 QEMU releases) has passed, and will then be deleted after 19a further 3 year period has passed. It is recommended that a deprecated 20machine type is only used for incoming migrations and restore of saved state, 21for pre-existing VM deployments. They should be scheduled for updating to a 22newer machine type during an appropriate service window. Newly deployed VMs 23should exclusively use a non-deprecated machine type, with use of the most 24recent version highly recommended. Non-versioned machine types follow the 25general feature deprecation policy. 26 27What follows is a list of all features currently marked as 28deprecated. 29 30System emulator command line arguments 31-------------------------------------- 32 33Short-form boolean options (since 6.0) 34'''''''''''''''''''''''''''''''''''''' 35 36Boolean options such as ``share=on``/``share=off`` could be written 37in short form as ``share`` and ``noshare``. This is now deprecated 38and will cause a warning. 39 40``delay`` option for socket character devices (since 6.0) 41''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 42 43The replacement for the ``nodelay`` short-form boolean option is ``nodelay=on`` 44rather than ``delay=off``. 45 46Plugin argument passing through ``arg=<string>`` (since 6.1) 47'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 48 49Passing TCG plugins arguments through ``arg=`` is redundant is makes the 50command-line less readable, especially when the argument itself consist of a 51name and a value, e.g. ``-plugin plugin_name,arg="arg_name=arg_value"``. 52Therefore, the usage of ``arg`` is redundant. Single-word arguments are treated 53as short-form boolean values, and passed to plugins as ``arg_name=on``. 54However, short-form booleans are deprecated and full explicit ``arg_name=on`` 55form is preferred. 56 57``-smp`` (Unsupported "parameter=1" SMP configurations) (since 9.0) 58''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 59 60Specified CPU topology parameters must be supported by the machine. 61 62In the SMP configuration, users should provide the CPU topology parameters that 63are supported by the target machine. 64 65However, historically it was allowed for users to specify the unsupported 66topology parameter as "1", which is meaningless. So support for this kind of 67configurations (e.g. -smp drawers=1,books=1,clusters=1 for x86 PC machine) is 68marked deprecated since 9.0, users have to ensure that all the topology members 69described with -smp are supported by the target machine. 70 71``-old-param`` option for booting Arm kernels via param_struct (since 10.0) 72''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 73 74The ``-old-param`` command line option is specific to Arm targets: 75it is used when directly booting a guest kernel to pass it the 76command line and other information via the old ``param_struct`` ABI, 77rather than the newer ATAGS or DTB mechanisms. This option was only 78ever needed to support ancient kernels on some old board types 79like the ``akita`` or ``terrier``; it has been deprecated in the 80kernel since 2001. None of the board types QEMU supports need 81``param_struct`` support, so this option has been deprecated and will 82be removed in a future QEMU version. 83 84User-mode emulator command line arguments 85----------------------------------------- 86 87``-p`` (since 9.0) 88'''''''''''''''''' 89 90The ``-p`` option pretends to control the host page size. However, 91it is not possible to change the host page size, and using the 92option only causes failures. 93 94QEMU Machine Protocol (QMP) commands 95------------------------------------ 96 97``blockdev-open-tray``, ``blockdev-close-tray`` argument ``device`` (since 2.8) 98''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 99 100Use argument ``id`` instead. 101 102``eject`` argument ``device`` (since 2.8) 103''''''''''''''''''''''''''''''''''''''''' 104 105Use argument ``id`` instead. 106 107``blockdev-change-medium`` argument ``device`` (since 2.8) 108'''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 109 110Use argument ``id`` instead. 111 112``block_set_io_throttle`` argument ``device`` (since 2.8) 113''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 114 115Use argument ``id`` instead. 116 117``blockdev-add`` empty string argument ``backing`` (since 2.10) 118''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 119 120Use argument value ``null`` instead. 121 122``block-commit`` arguments ``base`` and ``top`` (since 3.1) 123''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 124 125Use arguments ``base-node`` and ``top-node`` instead. 126 127``nbd-server-add`` and ``nbd-server-remove`` (since 5.2) 128'''''''''''''''''''''''''''''''''''''''''''''''''''''''' 129 130Use the more generic commands ``block-export-add`` and ``block-export-del`` 131instead. As part of this deprecation, where ``nbd-server-add`` used a 132single ``bitmap``, the new ``block-export-add`` uses a list of ``bitmaps``. 133 134``query-qmp-schema`` return value member ``values`` (since 6.2) 135''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 136 137Member ``values`` in return value elements with meta-type ``enum`` is 138deprecated. Use ``members`` instead. 139 140``drive-backup`` (since 6.2) 141'''''''''''''''''''''''''''' 142 143Use ``blockdev-backup`` in combination with ``blockdev-add`` instead. 144This change primarily separates the creation/opening process of the backup 145target with explicit, separate steps. ``blockdev-backup`` uses mostly the 146same arguments as ``drive-backup``, except the ``format`` and ``mode`` 147options are removed in favor of using explicit ``blockdev-create`` and 148``blockdev-add`` calls. See :doc:`/interop/live-block-operations` for 149details. 150 151``block-job-pause`` (since 10.1) 152'''''''''''''''''''''''''''''''' 153 154Use ``job-pause`` instead. The only difference is that ``job-pause`` 155always reports GenericError on failure when ``block-job-pause`` reports 156DeviceNotActive when block-job is not found. 157 158``block-job-resume`` (since 10.1) 159''''''''''''''''''''''''''''''''' 160 161Use ``job-resume`` instead. The only difference is that ``job-resume`` 162always reports GenericError on failure when ``block-job-resume`` reports 163DeviceNotActive when block-job is not found. 164 165``block-job-complete`` (since 10.1) 166''''''''''''''''''''''''''''''''''' 167 168Use ``job-complete`` instead. The only difference is that ``job-complete`` 169always reports GenericError on failure when ``block-job-complete`` reports 170DeviceNotActive when block-job is not found. 171 172``block-job-dismiss`` (since 10.1) 173'''''''''''''''''''''''''''''''''' 174 175Use ``job-dismiss`` instead. 176 177``block-job-finalize`` (since 10.1) 178''''''''''''''''''''''''''''''''''' 179 180Use ``job-finalize`` instead. 181 182``query-migrationthreads`` (since 9.2) 183'''''''''''''''''''''''''''''''''''''' 184 185To be removed with no replacement, as it reports only a limited set of 186threads (for example, it only reports source side of multifd threads, 187without reporting any destination threads, or non-multifd source threads). 188For debugging purpose, please use ``-name $VM,debug-threads=on`` instead. 189 190Incorrectly typed ``device_add`` arguments (since 6.2) 191'''''''''''''''''''''''''''''''''''''''''''''''''''''' 192 193Due to shortcomings in the internal implementation of ``device_add``, QEMU 194incorrectly accepts certain invalid arguments: Any object or list arguments are 195silently ignored. Other argument types are not checked, but an implicit 196conversion happens, so that e.g. string values can be assigned to integer 197device properties or vice versa. 198 199This is a bug in QEMU that will be fixed in the future so that previously 200accepted incorrect commands will return an error. Users should make sure that 201all arguments passed to ``device_add`` are consistent with the documented 202property types. 203 204Host Architectures 205------------------ 206 207Big endian MIPS since 7.2; 32-bit little endian MIPS since 9.2 208'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 209 210As Debian 10 ("Buster") moved into LTS the big endian 32 bit version of 211MIPS moved out of support making it hard to maintain our 212cross-compilation CI tests of the architecture. As we no longer have 213CI coverage support may bitrot away before the deprecation process 214completes. 215 216Likewise, the little endian variant of 32 bit MIPS is not supported by 217Debian 13 ("Trixie") and newer. 218 21964 bit little endian MIPS is still a supported host architecture. 220 221System emulation on 32-bit x86 hosts (since 8.0) 222'''''''''''''''''''''''''''''''''''''''''''''''' 223 224Support for 32-bit x86 host deployments is increasingly uncommon in mainstream 225OS distributions given the widespread availability of 64-bit x86 hardware. 226The QEMU project no longer considers 32-bit x86 support for system emulation to 227be an effective use of its limited resources, and thus intends to discontinue 228it. Since all recent x86 hardware from the past >10 years is capable of the 22964-bit x86 extensions, a corresponding 64-bit OS should be used instead. 230 231TCG Plugin support not enabled by default on 32-bit hosts (since 9.2) 232''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 233 234While it is still possible to enable TCG plugin support for 32-bit 235hosts there are a number of potential pitfalls when instrumenting 23664-bit guests. The plugin APIs typically pass most addresses as 237uint64_t but practices like encoding that address in a host pointer 238for passing as user-data will lose data. As most software analysis 239benefits from having plenty of host memory it seems reasonable to 240encourage users to use 64 bit builds of QEMU for analysis work 241whatever targets they are instrumenting. 242 243TCG Plugin support not enabled by default with TCI (since 9.2) 244'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 245 246While the TCG interpreter can interpret the TCG ops used by plugins it 247is going to be so much slower it wouldn't make sense for any serious 248instrumentation. Due to implementation differences there will also be 249anomalies in things like memory instrumentation. 250 25132-bit host operating systems (since 10.0) 252'''''''''''''''''''''''''''''''''''''''''' 253 254Keeping 32-bit host support alive is a substantial burden for the 255QEMU project. Thus QEMU will in future drop the support for all 25632-bit host systems. 257 258linux-user mode CPUs 259-------------------- 260 261iwMMXt emulation and the ``pxa`` CPUs (since 10.0) 262'''''''''''''''''''''''''''''''''''''''''''''''''' 263 264The ``pxa`` CPU family (``pxa250``, ``pxa255``, ``pxa260``, 265``pxa261``, ``pxa262``, ``pxa270-a0``, ``pxa270-a1``, ``pxa270``, 266``pxa270-b0``, ``pxa270-b1``, ``pxa270-c0``, ``pxa270-c5``) are no 267longer used in system emulation, because all the machine types which 268used these CPUs were removed in the QEMU 9.2 release. These CPUs can 269now only be used in linux-user mode, and to do that you would have to 270explicitly select one of these CPUs with the ``-cpu`` command line 271option or the ``QEMU_CPU`` environment variable. 272 273We don't believe that anybody is using the iwMMXt emulation, and we do 274not have any tests to validate it or any real hardware or similar 275known-good implementation to test against. GCC is in the process of 276dropping their support for iwMMXt codegen. These CPU types are 277therefore deprecated in QEMU, and will be removed in a future release. 278 279System emulator CPUs 280-------------------- 281 282``power5+`` and ``power7+`` CPU names (since 9.0) 283''''''''''''''''''''''''''''''''''''''''''''''''' 284 285The character "+" in device (and thus also CPU) names is not allowed 286in the QEMU object model anymore. ``power5+``, ``power5+_v2.1``, 287``power7+`` and ``power7+_v2.1`` are currently still supported via 288an alias, but for consistency these will get removed in a future 289release, too. Use ``power5p_v2.1`` and ``power7p_v2.1`` instead. 290 291``Sun-UltraSparc-IIIi+`` and ``Sun-UltraSparc-IV+`` CPU names (since 9.1) 292''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 293 294The character "+" in device (and thus also CPU) names is not allowed 295in the QEMU object model anymore. ``Sun-UltraSparc-IIIi+`` and 296``Sun-UltraSparc-IV+`` are currently still supported via a workaround, 297but for consistency these will get removed in a future release, too. 298Use ``Sun-UltraSparc-IIIi-plus`` and ``Sun-UltraSparc-IV-plus`` instead. 299 300PPC 405 CPUs (since 10.0) 301''''''''''''''''''''''''' 302 303The PPC 405 CPU has no known users and the ``ref405ep`` machine was 304removed in QEMU 10.0. Since the IBM POWER [8-11] processors uses an 305embedded 405 for power management (OCC) and other internal tasks, it 306is theoretically possible to use QEMU to model them. Let's keep the 307CPU implementation for a while before removing all support. 308 309System emulator machines 310------------------------ 311 312Versioned machine types (aarch64, arm, i386, m68k, ppc64, s390x, x86_64) 313'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 314 315In accordance with our versioned machine type deprecation policy, all machine 316types with version |VER_MACHINE_DEPRECATION_VERSION|, or older, have been 317deprecated. 318 319Arm ``virt`` machine ``dtb-kaslr-seed`` property (since 7.1) 320'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 321 322The ``dtb-kaslr-seed`` property on the ``virt`` board has been 323deprecated; use the new name ``dtb-randomness`` instead. The new name 324better reflects the way this property affects all random data within 325the device tree blob, not just the ``kaslr-seed`` node. 326 327Big-Endian variants of MicroBlaze ``petalogix-ml605`` and ``xlnx-zynqmp-pmu`` machines (since 9.2) 328'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 329 330Both ``petalogix-ml605`` and ``xlnx-zynqmp-pmu`` were added for little endian 331CPUs. Big endian support is not tested. 332 333Mips ``mipssim`` machine (since 10.0) 334''''''''''''''''''''''''''''''''''''' 335 336Linux dropped support for this virtual machine type in kernel v3.7, and 337there does not seem to be anybody around who is still using this board 338in QEMU: Most former MIPS-related people are working on other architectures 339in their everyday job nowadays, and we are also not aware of anybody still 340using old binaries with this board (i.e. there is also no binary available 341online to check that this board did not completely bitrot yet). It is 342recommended to use another MIPS machine for future MIPS code development 343instead. 344 345RISC-V default machine option (since 10.0) 346'''''''''''''''''''''''''''''''''''''''''' 347 348RISC-V defines ``spike`` as the default machine if no machine option is 349given in the command line. This happens because ``spike`` is the first 350RISC-V machine implemented in QEMU and setting it as default was 351convenient at that time. Now we have 7 riscv64 and 6 riscv32 machines 352and having ``spike`` as a default is no longer justified. This default 353will also promote situations where users think they're running ``virt`` 354(the most used RISC-V machine type in 10.0) when in fact they're 355running ``spike``. 356 357Removing the default machine option forces users to always set the machine 358they want to use and avoids confusion. Existing users of the ``spike`` 359machine must ensure that they're setting the ``spike`` machine in the 360command line (``-M spike``). 361 362 363Backend options 364--------------- 365 366Using non-persistent backing file with pmem=on (since 6.1) 367'''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 368 369This option is used when ``memory-backend-file`` is consumed by emulated NVDIMM 370device. However enabling ``memory-backend-file.pmem`` option, when backing file 371is (a) not DAX capable or (b) not on a filesystem that support direct mapping 372of persistent memory, is not safe and may lead to data loss or corruption in case 373of host crash. 374Options are: 375 376 - modify VM configuration to set ``pmem=off`` to continue using fake NVDIMM 377 (without persistence guaranties) with backing file on non DAX storage 378 - move backing file to NVDIMM storage and keep ``pmem=on`` 379 (to have NVDIMM with persistence guaranties). 380 381Device options 382-------------- 383 384Emulated device options 385''''''''''''''''''''''' 386 387``-device nvme-ns,eui64-default=on|off`` (since 7.1) 388^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 389 390In QEMU versions 6.1, 6.2 and 7.0, the ``nvme-ns`` generates an EUI-64 391identifier that is not globally unique. If an EUI-64 identifier is required, the 392user must set it explicitly using the ``nvme-ns`` device parameter ``eui64``. 393 394``-device nvme,use-intel-id=on|off`` (since 7.1) 395^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 396 397The ``nvme`` device originally used a PCI Vendor/Device Identifier combination 398from Intel that was not properly allocated. Since version 5.2, the controller 399has used a properly allocated identifier. Deprecate the ``use-intel-id`` 400machine compatibility parameter. 401 402``-device cxl-type3,memdev=xxxx`` (since 8.0) 403^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 404 405The ``cxl-type3`` device initially only used a single memory backend. With 406the addition of volatile memory support, it is now necessary to distinguish 407between persistent and volatile memory backends. As such, memdev is deprecated 408in favor of persistent-memdev. 409 410 411RISC-V CPU properties which start with capital 'Z' (since 8.2) 412^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 413 414All RISC-V CPU properties which start with capital 'Z' are being deprecated 415starting in 8.2. The reason is that they were wrongly added with capital 'Z' 416in the past. CPU properties were later added with lower-case names, which 417is the format we want to use from now on. 418 419Users which try to use these deprecated properties will receive a warning 420recommending to switch to their stable counterparts: 421 422- "Zifencei" should be replaced with "zifencei" 423- "Zicsr" should be replaced with "zicsr" 424- "Zihintntl" should be replaced with "zihintntl" 425- "Zihintpause" should be replaced with "zihintpause" 426- "Zawrs" should be replaced with "zawrs" 427- "Zfa" should be replaced with "zfa" 428- "Zfh" should be replaced with "zfh" 429- "Zfhmin" should be replaced with "zfhmin" 430- "Zve32f" should be replaced with "zve32f" 431- "Zve64f" should be replaced with "zve64f" 432- "Zve64d" should be replaced with "zve64d" 433 434``-device sd-card,spec_version=1`` (since 9.1) 435^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 436 437SD physical layer specification v2.00 supersedes the v1.10 one. 438v2.00 is the default since QEMU 3.0.0. 439 440Block device options 441'''''''''''''''''''' 442 443``"backing": ""`` (since 2.12) 444^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 445 446In order to prevent QEMU from automatically opening an image's backing 447chain, use ``"backing": null`` instead. 448 449``rbd`` keyvalue pair encoded filenames: ``""`` (since 3.1) 450^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 451 452Options for ``rbd`` should be specified according to its runtime options, 453like other block drivers. Legacy parsing of keyvalue pair encoded 454filenames is useful to open images with the old format for backing files; 455These image files should be updated to use the current format. 456 457Example of legacy encoding:: 458 459 json:{"file.driver":"rbd", "file.filename":"rbd:rbd/name"} 460 461The above, converted to the current supported format:: 462 463 json:{"file.driver":"rbd", "file.pool":"rbd", "file.image":"name"} 464 465``iscsi,password=xxx`` (since 8.0) 466^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 467 468Specifying the iSCSI password in plain text on the command line using the 469``password`` option is insecure. The ``password-secret`` option should be 470used instead, to refer to a ``--object secret...`` instance that provides 471a password via a file, or encrypted. 472 473``gluster`` backend (since 9.2) 474^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 475 476According to https://marc.info/?l=fedora-devel-list&m=171934833215726 477the GlusterFS development effectively ended. Unless the development 478gains momentum again, the QEMU project will remove the gluster backend 479in a future release. 480 481 482Character device options 483'''''''''''''''''''''''' 484 485Backend ``memory`` (since 9.0) 486^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 487 488``memory`` is a deprecated synonym for ``ringbuf``. 489 490``reconnect`` (since 9.2) 491^^^^^^^^^^^^^^^^^^^^^^^^^ 492 493The ``reconnect`` option only allows specifying second granularity timeouts, 494which is not enough for all types of use cases, use ``reconnect-ms`` instead. 495 496 497Net device options 498'''''''''''''''''' 499 500Stream ``reconnect`` (since 9.2) 501^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 502 503The ``reconnect`` option only allows specifying second granularity timeouts, 504which is not enough for all types of use cases, use ``reconnect-ms`` instead. 505 506VFIO device options 507''''''''''''''''''' 508 509``-device vfio-calxeda-xgmac`` (since 10.0) 510^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 511The vfio-calxeda-xgmac device allows to assign a host Calxeda Highbank 51210Gb XGMAC Ethernet controller device ("calxeda,hb-xgmac" compatibility 513string) to a guest. Calxeda HW has been ewasted now and there is no point 514keeping that device. 515 516``-device vfio-amd-xgbe`` (since 10.0) 517^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 518The vfio-amd-xgbe device allows to assign a host AMD 10GbE controller 519to a guest ("amd,xgbe-seattle-v1a" compatibility string). AMD "Seattle" 520is not supported anymore and there is no point keeping that device. 521 522``-device vfio-platform`` (since 10.0) 523^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 524The vfio-platform device allows to assign a host platform device 525to a guest in a generic manner. Integrating a new device into 526the vfio-platform infrastructure requires some adaptation at 527both kernel and qemu level. No such attempt has been done for years 528and the conclusion is that vfio-platform has not got any traction. 529PCIe passthrough shall be the mainline solution. 530 531CPU device properties 532''''''''''''''''''''' 533 534``pcommit`` on x86 (since 9.1) 535^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 536 537The PCOMMIT instruction was never included in any physical processor. 538It was implemented as a no-op instruction in TCG up to QEMU 9.0, but 539only with ``-cpu max`` (which does not guarantee migration compatibility 540across versions). 541 542``pmu-num=n`` on RISC-V CPUs (since 8.2) 543^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 544 545In order to support more flexible counter configurations this has been replaced 546by a ``pmu-mask`` property. If set of counters is continuous then the mask can 547be calculated with ``((2 ^ n) - 1) << 3``. The least significant three bits 548must be left clear. 549 550 551Backwards compatibility 552----------------------- 553 554Runnability guarantee of CPU models (since 4.1) 555''''''''''''''''''''''''''''''''''''''''''''''' 556 557Previous versions of QEMU never changed existing CPU models in 558ways that introduced additional host software or hardware 559requirements to the VM. This allowed management software to 560safely change the machine type of an existing VM without 561introducing new requirements ("runnability guarantee"). This 562prevented CPU models from being updated to include CPU 563vulnerability mitigations, leaving guests vulnerable in the 564default configuration. 565 566The CPU model runnability guarantee won't apply anymore to 567existing CPU models. Management software that needs runnability 568guarantees must resolve the CPU model aliases using the 569``alias-of`` field returned by the ``query-cpu-definitions`` QMP 570command. 571 572While those guarantees are kept, the return value of 573``query-cpu-definitions`` will have existing CPU model aliases 574point to a version that doesn't break runnability guarantees 575(specifically, version 1 of those CPU models). In future QEMU 576versions, aliases will point to newer CPU model versions 577depending on the machine type, so management software must 578resolve CPU model aliases before starting a virtual machine. 579 580RISC-V "virt" board "riscv,delegate" DT property (since 9.1) 581'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 582 583The "riscv,delegate" DT property was added in QEMU 7.0 as part of 584the AIA APLIC support. The property changed name during the review 585process in Linux and the correct name ended up being 586"riscv,delegation". Changing the DT property name will break all 587available firmwares that are using the current (wrong) name. The 588property is kept as is in 9.1, together with "riscv,delegation", to 589give more time for firmware developers to change their code. 590 591Migration 592--------- 593 594``fd:`` URI when used for file migration (since 9.1) 595'''''''''''''''''''''''''''''''''''''''''''''''''''' 596 597The ``fd:`` URI can currently provide a file descriptor that 598references either a socket or a plain file. These are two different 599types of migration. In order to reduce ambiguity, the ``fd:`` URI 600usage of providing a file descriptor to a plain file has been 601deprecated in favor of explicitly using the ``file:`` URI with the 602file descriptor being passed as an ``fdset``. Refer to the ``add-fd`` 603command documentation for details on the ``fdset`` usage. 604 605``zero-blocks`` capability (since 9.2) 606'''''''''''''''''''''''''''''''''''''' 607 608The ``zero-blocks`` capability was part of the block migration which 609doesn't exist anymore since it was removed in QEMU v9.1. 610