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