xref: /qemu/docs/about/deprecated.rst (revision 159fb790)
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
14Prior to the 2.10.0 release there was no official policy on how
15long features would be deprecated prior to their removal, nor
16any documented list of which features were deprecated. Thus
17any features deprecated prior to 2.10.0 will be treated as if
18they were first deprecated in the 2.10.0 release.
19
20What follows is a list of all features currently marked as
21deprecated.
22
23System emulator command line arguments
24--------------------------------------
25
26Short-form boolean options (since 6.0)
27''''''''''''''''''''''''''''''''''''''
28
29Boolean options such as ``share=on``/``share=off`` could be written
30in short form as ``share`` and ``noshare``.  This is now deprecated
31and will cause a warning.
32
33``delay`` option for socket character devices (since 6.0)
34'''''''''''''''''''''''''''''''''''''''''''''''''''''''''
35
36The replacement for the ``nodelay`` short-form boolean option is ``nodelay=on``
37rather than ``delay=off``.
38
39Plugin argument passing through ``arg=<string>`` (since 6.1)
40''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
41
42Passing TCG plugins arguments through ``arg=`` is redundant is makes the
43command-line less readable, especially when the argument itself consist of a
44name and a value, e.g. ``-plugin plugin_name,arg="arg_name=arg_value"``.
45Therefore, the usage of ``arg`` is redundant. Single-word arguments are treated
46as short-form boolean values, and passed to plugins as ``arg_name=on``.
47However, short-form booleans are deprecated and full explicit ``arg_name=on``
48form is preferred.
49
50``-smp`` (Unsupported "parameter=1" SMP configurations) (since 9.0)
51'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
52
53Specified CPU topology parameters must be supported by the machine.
54
55In the SMP configuration, users should provide the CPU topology parameters that
56are supported by the target machine.
57
58However, historically it was allowed for users to specify the unsupported
59topology parameter as "1", which is meaningless. So support for this kind of
60configurations (e.g. -smp drawers=1,books=1,clusters=1 for x86 PC machine) is
61marked deprecated since 9.0, users have to ensure that all the topology members
62described with -smp are supported by the target machine.
63
64User-mode emulator command line arguments
65-----------------------------------------
66
67``-p`` (since 9.0)
68''''''''''''''''''
69
70The ``-p`` option pretends to control the host page size.  However,
71it is not possible to change the host page size, and using the
72option only causes failures.
73
74QEMU Machine Protocol (QMP) commands
75------------------------------------
76
77``blockdev-open-tray``, ``blockdev-close-tray`` argument ``device`` (since 2.8)
78'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
79
80Use argument ``id`` instead.
81
82``eject`` argument ``device`` (since 2.8)
83'''''''''''''''''''''''''''''''''''''''''
84
85Use argument ``id`` instead.
86
87``blockdev-change-medium`` argument ``device`` (since 2.8)
88''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
89
90Use argument ``id`` instead.
91
92``block_set_io_throttle`` argument ``device`` (since 2.8)
93'''''''''''''''''''''''''''''''''''''''''''''''''''''''''
94
95Use argument ``id`` instead.
96
97``blockdev-add`` empty string argument ``backing`` (since 2.10)
98'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
99
100Use argument value ``null`` instead.
101
102``block-commit`` arguments ``base`` and ``top`` (since 3.1)
103'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
104
105Use arguments ``base-node`` and ``top-node`` instead.
106
107``nbd-server-add`` and ``nbd-server-remove`` (since 5.2)
108''''''''''''''''''''''''''''''''''''''''''''''''''''''''
109
110Use the more generic commands ``block-export-add`` and ``block-export-del``
111instead.  As part of this deprecation, where ``nbd-server-add`` used a
112single ``bitmap``, the new ``block-export-add`` uses a list of ``bitmaps``.
113
114``query-qmp-schema`` return value member ``values`` (since 6.2)
115'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
116
117Member ``values`` in return value elements with meta-type ``enum`` is
118deprecated.  Use ``members`` instead.
119
120``drive-backup`` (since 6.2)
121''''''''''''''''''''''''''''
122
123Use ``blockdev-backup`` in combination with ``blockdev-add`` instead.
124This change primarily separates the creation/opening process of the backup
125target with explicit, separate steps. ``blockdev-backup`` uses mostly the
126same arguments as ``drive-backup``, except the ``format`` and ``mode``
127options are removed in favor of using explicit ``blockdev-create`` and
128``blockdev-add`` calls. See :doc:`/interop/live-block-operations` for
129details.
130
131Incorrectly typed ``device_add`` arguments (since 6.2)
132''''''''''''''''''''''''''''''''''''''''''''''''''''''
133
134Due to shortcomings in the internal implementation of ``device_add``, QEMU
135incorrectly accepts certain invalid arguments: Any object or list arguments are
136silently ignored. Other argument types are not checked, but an implicit
137conversion happens, so that e.g. string values can be assigned to integer
138device properties or vice versa.
139
140This is a bug in QEMU that will be fixed in the future so that previously
141accepted incorrect commands will return an error. Users should make sure that
142all arguments passed to ``device_add`` are consistent with the documented
143property types.
144
145QEMU Machine Protocol (QMP) events
146----------------------------------
147
148``MEM_UNPLUG_ERROR`` (since 6.2)
149''''''''''''''''''''''''''''''''''''''''''''''''''''''''
150
151Use the more generic event ``DEVICE_UNPLUG_GUEST_ERROR`` instead.
152
153``vcpu`` trace events (since 8.1)
154'''''''''''''''''''''''''''''''''
155
156The ability to instrument QEMU helper functions with vCPU-aware trace
157points was removed in 7.0. However QMP still exposed the vcpu
158parameter. This argument has now been deprecated and the remaining
159remaining trace points that used it are selected just by name.
160
161Host Architectures
162------------------
163
164BE MIPS (since 7.2)
165'''''''''''''''''''
166
167As Debian 10 ("Buster") moved into LTS the big endian 32 bit version of
168MIPS moved out of support making it hard to maintain our
169cross-compilation CI tests of the architecture. As we no longer have
170CI coverage support may bitrot away before the deprecation process
171completes. The little endian variants of MIPS (both 32 and 64 bit) are
172still a supported host architecture.
173
174System emulation on 32-bit x86 hosts (since 8.0)
175''''''''''''''''''''''''''''''''''''''''''''''''
176
177Support for 32-bit x86 host deployments is increasingly uncommon in mainstream
178OS distributions given the widespread availability of 64-bit x86 hardware.
179The QEMU project no longer considers 32-bit x86 support for system emulation to
180be an effective use of its limited resources, and thus intends to discontinue
181it. Since all recent x86 hardware from the past >10 years is capable of the
18264-bit x86 extensions, a corresponding 64-bit OS should be used instead.
183
184
185System emulator CPUs
186--------------------
187
188``power5+`` and ``power7+`` CPU names (since 9.0)
189'''''''''''''''''''''''''''''''''''''''''''''''''
190
191The character "+" in device (and thus also CPU) names is not allowed
192in the QEMU object model anymore. ``power5+``, ``power5+_v2.1``,
193``power7+`` and ``power7+_v2.1`` are currently still supported via
194an alias, but for consistency these will get removed in a future
195release, too. Use ``power5p_v2.1`` and ``power7p_v2.1`` instead.
196
197CRIS CPU architecture (since 9.0)
198'''''''''''''''''''''''''''''''''
199
200The CRIS architecture was pulled from Linux in 4.17 and the compiler
201is no longer packaged in any distro making it harder to run the
202``check-tcg`` tests. Unless we can improve the testing situation there
203is a chance the code will bitrot without anyone noticing.
204
205System emulator machines
206------------------------
207
208Arm ``virt`` machine ``dtb-kaslr-seed`` property (since 7.1)
209''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
210
211The ``dtb-kaslr-seed`` property on the ``virt`` board has been
212deprecated; use the new name ``dtb-randomness`` instead. The new name
213better reflects the way this property affects all random data within
214the device tree blob, not just the ``kaslr-seed`` node.
215
216``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2)
217'''''''''''''''''''''''''''''''''''''''''''''''''''''
218
219These old machine types are quite neglected nowadays and thus might have
220various pitfalls with regards to live migration. Use a newer machine type
221instead.
222
223``shix`` (since 9.0)
224''''''''''''''''''''
225
226The machine is no longer in existence and has been long unmaintained
227in QEMU. This also holds for the TC51828 16MiB flash that it uses.
228
229``pseries-2.1`` up to ``pseries-2.12`` (since 9.0)
230''''''''''''''''''''''''''''''''''''''''''''''''''
231
232Older pseries machines before version 3.0 have undergone many changes
233to correct issues, mostly regarding migration compatibility. These are
234no longer maintained and removing them will make the code easier to
235read and maintain. Use versions 3.0 and above as a replacement.
236
237Arm machines ``akita``, ``borzoi``, ``cheetah``, ``connex``, ``mainstone``, ``n800``, ``n810``, ``spitz``, ``terrier``, ``tosa``, ``verdex``, ``z2`` (since 9.0)
238''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
239
240QEMU includes models of some machine types where the QEMU code that
241emulates their SoCs is very old and unmaintained. This code is now
242blocking our ability to move forward with various changes across
243the codebase, and over many years nobody has been interested in
244trying to modernise it. We don't expect any of these machines to have
245a large number of users, because they're all modelling hardware that
246has now passed away into history. We are therefore dropping support
247for all machine types using the PXA2xx and OMAP2 SoCs. We are also
248dropping the ``cheetah`` OMAP1 board, because we don't have any
249test images for it and don't know of anybody who does; the ``sx1``
250and ``sx1-v1`` OMAP1 machines remain supported for now.
251
252Backend options
253---------------
254
255Using non-persistent backing file with pmem=on (since 6.1)
256''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
257
258This option is used when ``memory-backend-file`` is consumed by emulated NVDIMM
259device. However enabling ``memory-backend-file.pmem`` option, when backing file
260is (a) not DAX capable or (b) not on a filesystem that support direct mapping
261of persistent memory, is not safe and may lead to data loss or corruption in case
262of host crash.
263Options are:
264
265    - modify VM configuration to set ``pmem=off`` to continue using fake NVDIMM
266      (without persistence guaranties) with backing file on non DAX storage
267    - move backing file to NVDIMM storage and keep ``pmem=on``
268      (to have NVDIMM with persistence guaranties).
269
270Device options
271--------------
272
273Emulated device options
274'''''''''''''''''''''''
275
276``-device virtio-blk,scsi=on|off`` (since 5.0)
277^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
278
279The virtio-blk SCSI passthrough feature is a legacy VIRTIO feature.  VIRTIO 1.0
280and later do not support it because the virtio-scsi device was introduced for
281full SCSI support.  Use virtio-scsi instead when SCSI passthrough is required.
282
283Note this also applies to ``-device virtio-blk-pci,scsi=on|off``, which is an
284alias.
285
286``-device nvme-ns,eui64-default=on|off`` (since 7.1)
287^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
288
289In QEMU versions 6.1, 6.2 and 7.0, the ``nvme-ns`` generates an EUI-64
290identifier that is not globally unique. If an EUI-64 identifier is required, the
291user must set it explicitly using the ``nvme-ns`` device parameter ``eui64``.
292
293``-device nvme,use-intel-id=on|off`` (since 7.1)
294^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
295
296The ``nvme`` device originally used a PCI Vendor/Device Identifier combination
297from Intel that was not properly allocated. Since version 5.2, the controller
298has used a properly allocated identifier. Deprecate the ``use-intel-id``
299machine compatibility parameter.
300
301``-device cxl-type3,memdev=xxxx`` (since 8.0)
302^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
303
304The ``cxl-type3`` device initially only used a single memory backend.  With
305the addition of volatile memory support, it is now necessary to distinguish
306between persistent and volatile memory backends.  As such, memdev is deprecated
307in favor of persistent-memdev.
308
309``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
310^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
311
312The 9p ``proxy`` filesystem backend driver has been deprecated and will be
313removed (along with its proxy helper daemon) in a future version of QEMU. Please
314use ``-fsdev local`` or ``-virtfs local`` for using the 9p ``local`` filesystem
315backend, or alternatively consider deploying virtiofsd instead.
316
317The 9p ``proxy`` backend was originally developed as an alternative to the 9p
318``local`` backend. The idea was to enhance security by dispatching actual low
319level filesystem operations from 9p server (QEMU process) over to a separate
320process (the virtfs-proxy-helper binary). However this alternative never gained
321momentum. The proxy backend is much slower than the local backend, hasn't seen
322any development in years, and showed to be less secure, especially due to the
323fact that its helper daemon must be run as root, whereas with the local backend
324QEMU is typically run as unprivileged user and allows to tighten behaviour by
325mapping permissions et al by using its 'mapped' security model option.
326
327Nowadays it would make sense to reimplement the ``proxy`` backend by using
328QEMU's ``vhost`` feature, which would eliminate the high latency costs under
329which the 9p ``proxy`` backend currently suffers. However as of to date nobody
330has indicated plans for such kind of reimplementation unfortunately.
331
332RISC-V 'any' CPU type ``-cpu any`` (since 8.2)
333^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
334
335The 'any' CPU type was introduced back in 2018 and has been around since the
336initial RISC-V QEMU port. Its usage has always been unclear: users don't know
337what to expect from a CPU called 'any', and in fact the CPU does not do anything
338special that isn't already done by the default CPUs rv32/rv64.
339
340After the introduction of the 'max' CPU type, RISC-V now has a good coverage
341of generic CPUs: rv32 and rv64 as default CPUs and 'max' as a feature complete
342CPU for both 32 and 64 bit builds. Users are then discouraged to use the 'any'
343CPU type starting in 8.2.
344
345RISC-V CPU properties which start with capital 'Z' (since 8.2)
346^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
347
348All RISC-V CPU properties which start with capital 'Z' are being deprecated
349starting in 8.2. The reason is that they were wrongly added with capital 'Z'
350in the past. CPU properties were later added with lower-case names, which
351is the format we want to use from now on.
352
353Users which try to use these deprecated properties will receive a warning
354recommending to switch to their stable counterparts:
355
356- "Zifencei" should be replaced with "zifencei"
357- "Zicsr" should be replaced with "zicsr"
358- "Zihintntl" should be replaced with "zihintntl"
359- "Zihintpause" should be replaced with "zihintpause"
360- "Zawrs" should be replaced with "zawrs"
361- "Zfa" should be replaced with "zfa"
362- "Zfh" should be replaced with "zfh"
363- "Zfhmin" should be replaced with "zfhmin"
364- "Zve32f" should be replaced with "zve32f"
365- "Zve64f" should be replaced with "zve64f"
366- "Zve64d" should be replaced with "zve64d"
367
368Block device options
369''''''''''''''''''''
370
371``"backing": ""`` (since 2.12)
372^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
373
374In order to prevent QEMU from automatically opening an image's backing
375chain, use ``"backing": null`` instead.
376
377``rbd`` keyvalue pair encoded filenames: ``""`` (since 3.1)
378^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
379
380Options for ``rbd`` should be specified according to its runtime options,
381like other block drivers.  Legacy parsing of keyvalue pair encoded
382filenames is useful to open images with the old format for backing files;
383These image files should be updated to use the current format.
384
385Example of legacy encoding::
386
387  json:{"file.driver":"rbd", "file.filename":"rbd:rbd/name"}
388
389The above, converted to the current supported format::
390
391  json:{"file.driver":"rbd", "file.pool":"rbd", "file.image":"name"}
392
393``iscsi,password=xxx`` (since 8.0)
394^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
395
396Specifying the iSCSI password in plain text on the command line using the
397``password`` option is insecure. The ``password-secret`` option should be
398used instead, to refer to a ``--object secret...`` instance that provides
399a password via a file, or encrypted.
400
401Character device options
402''''''''''''''''''''''''
403
404Backend ``memory`` (since 9.0)
405^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
406
407``memory`` is a deprecated synonym for ``ringbuf``.
408
409CPU device properties
410'''''''''''''''''''''
411
412``pmu-num=n`` on RISC-V CPUs (since 8.2)
413^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
414
415In order to support more flexible counter configurations this has been replaced
416by a ``pmu-mask`` property. If set of counters is continuous then the mask can
417be calculated with ``((2 ^ n) - 1) << 3``. The least significant three bits
418must be left clear.
419
420
421Backwards compatibility
422-----------------------
423
424Runnability guarantee of CPU models (since 4.1)
425'''''''''''''''''''''''''''''''''''''''''''''''
426
427Previous versions of QEMU never changed existing CPU models in
428ways that introduced additional host software or hardware
429requirements to the VM.  This allowed management software to
430safely change the machine type of an existing VM without
431introducing new requirements ("runnability guarantee").  This
432prevented CPU models from being updated to include CPU
433vulnerability mitigations, leaving guests vulnerable in the
434default configuration.
435
436The CPU model runnability guarantee won't apply anymore to
437existing CPU models.  Management software that needs runnability
438guarantees must resolve the CPU model aliases using the
439``alias-of`` field returned by the ``query-cpu-definitions`` QMP
440command.
441
442While those guarantees are kept, the return value of
443``query-cpu-definitions`` will have existing CPU model aliases
444point to a version that doesn't break runnability guarantees
445(specifically, version 1 of those CPU models).  In future QEMU
446versions, aliases will point to newer CPU model versions
447depending on the machine type, so management software must
448resolve CPU model aliases before starting a virtual machine.
449
450QEMU guest agent
451----------------
452
453``--blacklist`` command line option (since 7.2)
454'''''''''''''''''''''''''''''''''''''''''''''''
455
456``--blacklist`` has been replaced by ``--block-rpcs`` (which is a better
457wording for what this option does). The short form ``-b`` still stays
458the same and thus is the preferred way for scripts that should run with
459both, older and future versions of QEMU.
460
461``blacklist`` config file option (since 7.2)
462''''''''''''''''''''''''''''''''''''''''''''
463
464The ``blacklist`` config file option has been renamed to ``block-rpcs``
465(to be in sync with the renaming of the corresponding command line
466option).
467
468Migration
469---------
470
471``skipped`` MigrationStats field (since 8.1)
472''''''''''''''''''''''''''''''''''''''''''''
473
474``skipped`` field in Migration stats has been deprecated.  It hasn't
475been used for more than 10 years.
476
477``inc`` migrate command option (since 8.2)
478''''''''''''''''''''''''''''''''''''''''''
479
480Use blockdev-mirror with NBD instead.
481
482As an intermediate step the ``inc`` functionality can be achieved by
483setting the ``block-incremental`` migration parameter to ``true``.
484But this parameter is also deprecated.
485
486``blk`` migrate command option (since 8.2)
487''''''''''''''''''''''''''''''''''''''''''
488
489Use blockdev-mirror with NBD instead.
490
491As an intermediate step the ``blk`` functionality can be achieved by
492setting the ``block`` migration capability to ``true``.  But this
493capability is also deprecated.
494
495block migration (since 8.2)
496'''''''''''''''''''''''''''
497
498Block migration is too inflexible.  It needs to migrate all block
499devices or none.
500
501Please see "QMP invocation for live storage migration with
502``blockdev-mirror`` + NBD" in docs/interop/live-block-operations.rst
503for a detailed explanation.
504
505old compression method (since 8.2)
506''''''''''''''''''''''''''''''''''
507
508Compression method fails too much.  Too many races.  We are going to
509remove it if nobody fixes it.  For starters, migration-test
510compression tests are disabled because they fail randomly.  If you need
511compression, use multifd compression methods.
512