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``query-migrationthreads`` (since 9.2) 152'''''''''''''''''''''''''''''''''''''' 153 154To be removed with no replacement, as it reports only a limited set of 155threads (for example, it only reports source side of multifd threads, 156without reporting any destination threads, or non-multifd source threads). 157For debugging purpose, please use ``-name $VM,debug-threads=on`` instead. 158 159``block-job-pause`` (since 10.1) 160'''''''''''''''''''''''''''''''' 161 162Use ``job-pause`` instead. The only difference is that ``job-pause`` 163always reports GenericError on failure when ``block-job-pause`` reports 164DeviceNotActive when block-job is not found. 165 166``block-job-resume`` (since 10.1) 167''''''''''''''''''''''''''''''''' 168 169Use ``job-resume`` instead. The only difference is that ``job-resume`` 170always reports GenericError on failure when ``block-job-resume`` reports 171DeviceNotActive when block-job is not found. 172 173``block-job-complete`` (since 10.1) 174''''''''''''''''''''''''''''''''''' 175 176Use ``job-complete`` instead. The only difference is that ``job-complete`` 177always reports GenericError on failure when ``block-job-complete`` reports 178DeviceNotActive when block-job is not found. 179 180``block-job-dismiss`` (since 10.1) 181'''''''''''''''''''''''''''''''''' 182 183Use ``job-dismiss`` instead. 184 185``block-job-finalize`` (since 10.1) 186''''''''''''''''''''''''''''''''''' 187 188Use ``job-finalize`` instead. 189 190``migrate`` argument ``detach`` (since 10.1) 191'''''''''''''''''''''''''''''''''''''''''''' 192 193This argument has always been ignored. 194 195Host Architectures 196------------------ 197 198Big endian MIPS since 7.2; 32-bit little endian MIPS since 9.2 199'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 200 201As Debian 10 ("Buster") moved into LTS the big endian 32 bit version of 202MIPS moved out of support making it hard to maintain our 203cross-compilation CI tests of the architecture. As we no longer have 204CI coverage support may bitrot away before the deprecation process 205completes. 206 207Likewise, the little endian variant of 32 bit MIPS is not supported by 208Debian 13 ("Trixie") and newer. 209 21064 bit little endian MIPS is still a supported host architecture. 211 212System emulation on 32-bit x86 hosts (since 8.0) 213'''''''''''''''''''''''''''''''''''''''''''''''' 214 215Support for 32-bit x86 host deployments is increasingly uncommon in mainstream 216OS distributions given the widespread availability of 64-bit x86 hardware. 217The QEMU project no longer considers 32-bit x86 support for system emulation to 218be an effective use of its limited resources, and thus intends to discontinue 219it. Since all recent x86 hardware from the past >10 years is capable of the 22064-bit x86 extensions, a corresponding 64-bit OS should be used instead. 221 222TCG Plugin support not enabled by default on 32-bit hosts (since 9.2) 223''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 224 225While it is still possible to enable TCG plugin support for 32-bit 226hosts there are a number of potential pitfalls when instrumenting 22764-bit guests. The plugin APIs typically pass most addresses as 228uint64_t but practices like encoding that address in a host pointer 229for passing as user-data will lose data. As most software analysis 230benefits from having plenty of host memory it seems reasonable to 231encourage users to use 64 bit builds of QEMU for analysis work 232whatever targets they are instrumenting. 233 234TCG Plugin support not enabled by default with TCI (since 9.2) 235'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 236 237While the TCG interpreter can interpret the TCG ops used by plugins it 238is going to be so much slower it wouldn't make sense for any serious 239instrumentation. Due to implementation differences there will also be 240anomalies in things like memory instrumentation. 241 24232-bit host operating systems (since 10.0) 243'''''''''''''''''''''''''''''''''''''''''' 244 245Keeping 32-bit host support alive is a substantial burden for the 246QEMU project. Thus QEMU will in future drop the support for all 24732-bit host systems. 248 249linux-user mode CPUs 250-------------------- 251 252iwMMXt emulation and the ``pxa`` CPUs (since 10.0) 253'''''''''''''''''''''''''''''''''''''''''''''''''' 254 255The ``pxa`` CPU family (``pxa250``, ``pxa255``, ``pxa260``, 256``pxa261``, ``pxa262``, ``pxa270-a0``, ``pxa270-a1``, ``pxa270``, 257``pxa270-b0``, ``pxa270-b1``, ``pxa270-c0``, ``pxa270-c5``) are no 258longer used in system emulation, because all the machine types which 259used these CPUs were removed in the QEMU 9.2 release. These CPUs can 260now only be used in linux-user mode, and to do that you would have to 261explicitly select one of these CPUs with the ``-cpu`` command line 262option or the ``QEMU_CPU`` environment variable. 263 264We don't believe that anybody is using the iwMMXt emulation, and we do 265not have any tests to validate it or any real hardware or similar 266known-good implementation to test against. GCC is in the process of 267dropping their support for iwMMXt codegen. These CPU types are 268therefore deprecated in QEMU, and will be removed in a future release. 269 270System emulator CPUs 271-------------------- 272 273``power5+`` and ``power7+`` CPU names (since 9.0) 274''''''''''''''''''''''''''''''''''''''''''''''''' 275 276The character "+" in device (and thus also CPU) names is not allowed 277in the QEMU object model anymore. ``power5+``, ``power5+_v2.1``, 278``power7+`` and ``power7+_v2.1`` are currently still supported via 279an alias, but for consistency these will get removed in a future 280release, too. Use ``power5p_v2.1`` and ``power7p_v2.1`` instead. 281 282``Sun-UltraSparc-IIIi+`` and ``Sun-UltraSparc-IV+`` CPU names (since 9.1) 283''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 284 285The character "+" in device (and thus also CPU) names is not allowed 286in the QEMU object model anymore. ``Sun-UltraSparc-IIIi+`` and 287``Sun-UltraSparc-IV+`` are currently still supported via a workaround, 288but for consistency these will get removed in a future release, too. 289Use ``Sun-UltraSparc-IIIi-plus`` and ``Sun-UltraSparc-IV-plus`` instead. 290 291PPC 405 CPUs (since 10.0) 292''''''''''''''''''''''''' 293 294The PPC 405 CPU has no known users and the ``ref405ep`` machine was 295removed in QEMU 10.0. Since the IBM POWER [8-11] processors uses an 296embedded 405 for power management (OCC) and other internal tasks, it 297is theoretically possible to use QEMU to model them. Let's keep the 298CPU implementation for a while before removing all support. 299 300System emulator machines 301------------------------ 302 303Versioned machine types (aarch64, arm, i386, m68k, ppc64, s390x, x86_64) 304'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 305 306In accordance with our versioned machine type deprecation policy, all machine 307types with version |VER_MACHINE_DEPRECATION_VERSION|, or older, have been 308deprecated. 309 310Arm ``virt`` machine ``dtb-kaslr-seed`` property (since 7.1) 311'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 312 313The ``dtb-kaslr-seed`` property on the ``virt`` board has been 314deprecated; use the new name ``dtb-randomness`` instead. The new name 315better reflects the way this property affects all random data within 316the device tree blob, not just the ``kaslr-seed`` node. 317 318Mips ``mipssim`` machine (since 10.0) 319''''''''''''''''''''''''''''''''''''' 320 321Linux dropped support for this virtual machine type in kernel v3.7, and 322there does not seem to be anybody around who is still using this board 323in QEMU: Most former MIPS-related people are working on other architectures 324in their everyday job nowadays, and we are also not aware of anybody still 325using old binaries with this board (i.e. there is also no binary available 326online to check that this board did not completely bitrot yet). It is 327recommended to use another MIPS machine for future MIPS code development 328instead. 329 330RISC-V default machine option (since 10.0) 331'''''''''''''''''''''''''''''''''''''''''' 332 333RISC-V defines ``spike`` as the default machine if no machine option is 334given in the command line. This happens because ``spike`` is the first 335RISC-V machine implemented in QEMU and setting it as default was 336convenient at that time. Now we have 7 riscv64 and 6 riscv32 machines 337and having ``spike`` as a default is no longer justified. This default 338will also promote situations where users think they're running ``virt`` 339(the most used RISC-V machine type in 10.0) when in fact they're 340running ``spike``. 341 342Removing the default machine option forces users to always set the machine 343they want to use and avoids confusion. Existing users of the ``spike`` 344machine must ensure that they're setting the ``spike`` machine in the 345command line (``-M spike``). 346 347Arm ``highbank`` and ``midway`` machines (since 10.1) 348''''''''''''''''''''''''''''''''''''''''''''''''''''' 349 350There are no known users left for these machines (if you still use it, 351please write a mail to the qemu-devel mailing list). If you just want to 352boot a Cortex-A15 or Cortex-A9 Linux, use the ``virt`` machine instead. 353 354 355System emulator binaries 356------------------------ 357 358``qemu-system-microblazeel`` (since 10.1) 359''''''''''''''''''''''''''''''''''''''''' 360 361The ``qemu-system-microblaze`` binary can emulate little-endian machines 362now, too, so the separate binary ``qemu-system-microblazeel`` (with the 363``el`` suffix) for little-endian targets is not required anymore. The 364``petalogix-s3adsp1800`` machine can now be switched to little endian by 365setting its ``endianness`` property to ``little``. 366 367 368Backend options 369--------------- 370 371Using non-persistent backing file with pmem=on (since 6.1) 372'''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 373 374This option is used when ``memory-backend-file`` is consumed by emulated NVDIMM 375device. However enabling ``memory-backend-file.pmem`` option, when backing file 376is (a) not DAX capable or (b) not on a filesystem that support direct mapping 377of persistent memory, is not safe and may lead to data loss or corruption in case 378of host crash. 379Options are: 380 381 - modify VM configuration to set ``pmem=off`` to continue using fake NVDIMM 382 (without persistence guaranties) with backing file on non DAX storage 383 - move backing file to NVDIMM storage and keep ``pmem=on`` 384 (to have NVDIMM with persistence guaranties). 385 386Device options 387-------------- 388 389Emulated device options 390''''''''''''''''''''''' 391 392``-device nvme-ns,eui64-default=on|off`` (since 7.1) 393^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 394 395In QEMU versions 6.1, 6.2 and 7.0, the ``nvme-ns`` generates an EUI-64 396identifier that is not globally unique. If an EUI-64 identifier is required, the 397user must set it explicitly using the ``nvme-ns`` device parameter ``eui64``. 398 399``-device nvme,use-intel-id=on|off`` (since 7.1) 400^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 401 402The ``nvme`` device originally used a PCI Vendor/Device Identifier combination 403from Intel that was not properly allocated. Since version 5.2, the controller 404has used a properly allocated identifier. Deprecate the ``use-intel-id`` 405machine compatibility parameter. 406 407``-device cxl-type3,memdev=xxxx`` (since 8.0) 408^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 409 410The ``cxl-type3`` device initially only used a single memory backend. With 411the addition of volatile memory support, it is now necessary to distinguish 412between persistent and volatile memory backends. As such, memdev is deprecated 413in favor of persistent-memdev. 414 415 416RISC-V CPU properties which start with capital 'Z' (since 8.2) 417^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 418 419All RISC-V CPU properties which start with capital 'Z' are being deprecated 420starting in 8.2. The reason is that they were wrongly added with capital 'Z' 421in the past. CPU properties were later added with lower-case names, which 422is the format we want to use from now on. 423 424Users which try to use these deprecated properties will receive a warning 425recommending to switch to their stable counterparts: 426 427- "Zifencei" should be replaced with "zifencei" 428- "Zicsr" should be replaced with "zicsr" 429- "Zihintntl" should be replaced with "zihintntl" 430- "Zihintpause" should be replaced with "zihintpause" 431- "Zawrs" should be replaced with "zawrs" 432- "Zfa" should be replaced with "zfa" 433- "Zfh" should be replaced with "zfh" 434- "Zfhmin" should be replaced with "zfhmin" 435- "Zve32f" should be replaced with "zve32f" 436- "Zve64f" should be replaced with "zve64f" 437- "Zve64d" should be replaced with "zve64d" 438 439``-device sd-card,spec_version=1`` (since 9.1) 440^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 441 442SD physical layer specification v2.00 supersedes the v1.10 one. 443v2.00 is the default since QEMU 3.0.0. 444 445Block device options 446'''''''''''''''''''' 447 448``"backing": ""`` (since 2.12) 449^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 450 451In order to prevent QEMU from automatically opening an image's backing 452chain, use ``"backing": null`` instead. 453 454``rbd`` keyvalue pair encoded filenames: ``""`` (since 3.1) 455^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 456 457Options for ``rbd`` should be specified according to its runtime options, 458like other block drivers. Legacy parsing of keyvalue pair encoded 459filenames is useful to open images with the old format for backing files; 460These image files should be updated to use the current format. 461 462Example of legacy encoding:: 463 464 json:{"file.driver":"rbd", "file.filename":"rbd:rbd/name"} 465 466The above, converted to the current supported format:: 467 468 json:{"file.driver":"rbd", "file.pool":"rbd", "file.image":"name"} 469 470``iscsi,password=xxx`` (since 8.0) 471^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 472 473Specifying the iSCSI password in plain text on the command line using the 474``password`` option is insecure. The ``password-secret`` option should be 475used instead, to refer to a ``--object secret...`` instance that provides 476a password via a file, or encrypted. 477 478``gluster`` backend (since 9.2) 479^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 480 481According to https://marc.info/?l=fedora-devel-list&m=171934833215726 482the GlusterFS development effectively ended. Unless the development 483gains momentum again, the QEMU project will remove the gluster backend 484in a future release. 485 486 487Character device options 488'''''''''''''''''''''''' 489 490Backend ``memory`` (since 9.0) 491^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 492 493``memory`` is a deprecated synonym for ``ringbuf``. 494 495``reconnect`` (since 9.2) 496^^^^^^^^^^^^^^^^^^^^^^^^^ 497 498The ``reconnect`` option only allows specifying second granularity timeouts, 499which is not enough for all types of use cases, use ``reconnect-ms`` instead. 500 501 502Net device options 503'''''''''''''''''' 504 505Stream ``reconnect`` (since 9.2) 506^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 507 508The ``reconnect`` option only allows specifying second granularity timeouts, 509which is not enough for all types of use cases, use ``reconnect-ms`` instead. 510 511VFIO device options 512''''''''''''''''''' 513 514``-device vfio-calxeda-xgmac`` (since 10.0) 515^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 516The vfio-calxeda-xgmac device allows to assign a host Calxeda Highbank 51710Gb XGMAC Ethernet controller device ("calxeda,hb-xgmac" compatibility 518string) to a guest. Calxeda HW has been ewasted now and there is no point 519keeping that device. 520 521``-device vfio-amd-xgbe`` (since 10.0) 522^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 523The vfio-amd-xgbe device allows to assign a host AMD 10GbE controller 524to a guest ("amd,xgbe-seattle-v1a" compatibility string). AMD "Seattle" 525is not supported anymore and there is no point keeping that device. 526 527``-device vfio-platform`` (since 10.0) 528^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 529The vfio-platform device allows to assign a host platform device 530to a guest in a generic manner. Integrating a new device into 531the vfio-platform infrastructure requires some adaptation at 532both kernel and qemu level. No such attempt has been done for years 533and the conclusion is that vfio-platform has not got any traction. 534PCIe passthrough shall be the mainline solution. 535 536CPU device properties 537''''''''''''''''''''' 538 539``pmu-num=n`` on RISC-V CPUs (since 8.2) 540^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 541 542In order to support more flexible counter configurations this has been replaced 543by a ``pmu-mask`` property. If set of counters is continuous then the mask can 544be calculated with ``((2 ^ n) - 1) << 3``. The least significant three bits 545must be left clear. 546 547 548``pcommit`` on x86 (since 9.1) 549^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 550 551The PCOMMIT instruction was never included in any physical processor. 552It was implemented as a no-op instruction in TCG up to QEMU 9.0, but 553only with ``-cpu max`` (which does not guarantee migration compatibility 554across versions). 555 556Backwards compatibility 557----------------------- 558 559Runnability guarantee of CPU models (since 4.1) 560''''''''''''''''''''''''''''''''''''''''''''''' 561 562Previous versions of QEMU never changed existing CPU models in 563ways that introduced additional host software or hardware 564requirements to the VM. This allowed management software to 565safely change the machine type of an existing VM without 566introducing new requirements ("runnability guarantee"). This 567prevented CPU models from being updated to include CPU 568vulnerability mitigations, leaving guests vulnerable in the 569default configuration. 570 571The CPU model runnability guarantee won't apply anymore to 572existing CPU models. Management software that needs runnability 573guarantees must resolve the CPU model aliases using the 574``alias-of`` field returned by the ``query-cpu-definitions`` QMP 575command. 576 577While those guarantees are kept, the return value of 578``query-cpu-definitions`` will have existing CPU model aliases 579point to a version that doesn't break runnability guarantees 580(specifically, version 1 of those CPU models). In future QEMU 581versions, aliases will point to newer CPU model versions 582depending on the machine type, so management software must 583resolve CPU model aliases before starting a virtual machine. 584 585RISC-V "virt" board "riscv,delegate" DT property (since 9.1) 586'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 587 588The "riscv,delegate" DT property was added in QEMU 7.0 as part of 589the AIA APLIC support. The property changed name during the review 590process in Linux and the correct name ended up being 591"riscv,delegation". Changing the DT property name will break all 592available firmwares that are using the current (wrong) name. The 593property is kept as is in 9.1, together with "riscv,delegation", to 594give more time for firmware developers to change their code. 595 596Migration 597--------- 598 599``fd:`` URI when used for file migration (since 9.1) 600'''''''''''''''''''''''''''''''''''''''''''''''''''' 601 602The ``fd:`` URI can currently provide a file descriptor that 603references either a socket or a plain file. These are two different 604types of migration. In order to reduce ambiguity, the ``fd:`` URI 605usage of providing a file descriptor to a plain file has been 606deprecated in favor of explicitly using the ``file:`` URI with the 607file descriptor being passed as an ``fdset``. Refer to the ``add-fd`` 608command documentation for details on the ``fdset`` usage. 609 610``zero-blocks`` capability (since 9.2) 611'''''''''''''''''''''''''''''''''''''' 612 613The ``zero-blocks`` capability was part of the block migration which 614doesn't exist anymore since it was removed in QEMU v9.1. 615