qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* Let's remove some deprecated stuff
@ 2021-04-29  9:59 Markus Armbruster
  2021-04-29 10:18 ` Gerd Hoffmann
                   ` (10 more replies)
  0 siblings, 11 replies; 33+ messages in thread
From: Markus Armbruster @ 2021-04-29  9:59 UTC (permalink / raw)
  To: qemu-devel
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Alex Bennée, Robert Hoo, Alistair Francis, Gerd Hoffmann,
	Stefan Hajnoczi, dirty.ice.hu, Philippe Mathieu-Daudé

If you're cc'ed, you added a section to docs/system/deprecated.rst that
is old enough to permit removal.  This is *not* a demand to remove, it's
a polite request to consider whether the time for removal has come.
Extra points for telling us in a reply.  "We should remove, but I can't
do it myself right now" is a valid answer.  Let's review the file:

    System emulator command line arguments
    --------------------------------------

Kővágó, Zoltán:

    ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    The ``-audiodev`` argument is now the preferred way to specify audio
    backend settings instead of environment variables.  To ease migration to
    the new format, the ``-audiodev-help`` option can be used to convert
    the current values of the environment variables to ``-audiodev`` options.

Kővágó, Zoltán:

    Creating sound card devices and vnc without ``audiodev=`` property (since 4.2)
    ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    When not using the deprecated legacy audio config, each sound card
    should specify an ``audiodev=`` property.  Additionally, when using
    vnc, you should specify an ``audiodev=`` property if you plan to
    transmit audio through the VNC protocol.

Gerd Hoffmann:

    Creating sound card devices using ``-soundhw`` (since 5.1)
    ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    Sound card devices should be created using ``-device`` instead.  The
    names are the same for most devices.  The exceptions are ``hda`` which
    needs two devices (``-device intel-hda -device hda-duplex``) and
    ``pcspk`` which can be activated using ``-machine
    pcspk-audiodev=<name>``.

[...]

Alistair Francis:

    RISC-V ``-bios`` (since 5.1)
    ''''''''''''''''''''''''''''

    QEMU 4.1 introduced support for the -bios option in QEMU for RISC-V for the
    RISC-V virt machine and sifive_u machine. QEMU 4.1 had no changes to the
    default behaviour to avoid breakages.

    QEMU 5.1 changes the default behaviour from ``-bios none`` to ``-bios default``.

    QEMU 5.1 has three options:
     1. ``-bios default`` - This is the current default behavior if no -bios option
          is included. This option will load the default OpenSBI firmware automatically.
          The firmware is included with the QEMU release and no user interaction is
          required. All a user needs to do is specify the kernel they want to boot
          with the -kernel option
     2. ``-bios none`` - QEMU will not automatically load any firmware. It is up
          to the user to load all the images they need.
     3. ``-bios <file>`` - Tells QEMU to load the specified file as the firmwrae.

[...]

    QEMU Machine Protocol (QMP) commands
    ------------------------------------

Myself, but I only documented it; it's actually Kevin Wolf:

    ``blockdev-open-tray``, ``blockdev-close-tray`` argument ``device`` (since 2.8.0)
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    Use argument ``id`` instead.

    ``eject`` argument ``device`` (since 2.8.0)
    '''''''''''''''''''''''''''''''''''''''''''

    Use argument ``id`` instead.

    ``blockdev-change-medium`` argument ``device`` (since 2.8.0)
    ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    Use argument ``id`` instead.

    ``block_set_io_throttle`` argument ``device`` (since 2.8.0)
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    Use argument ``id`` instead.

Myself:

    ``blockdev-add`` empty string argument ``backing`` (since 2.10.0)
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    Use argument value ``null`` instead.

Myself, but I only documented it; it's actually Kevin Wolf:

    ``block-commit`` arguments ``base`` and ``top`` (since 3.1.0)
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    Use arguments ``base-node`` and ``top-node`` instead.

Kevin Wolf:

    ``nbd-server-add`` and ``nbd-server-remove`` (since 5.2)
    ''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    Use the more generic commands ``block-export-add`` and ``block-export-del``
    instead.  As part of this deprecation, where ``nbd-server-add`` used a
    single ``bitmap``, the new ``block-export-add`` uses a list of ``bitmaps``.


[...]

    System emulator CPUS
    --------------------

Thomas Huth:

    ``moxie`` CPU (since 5.2.0)
    '''''''''''''''''''''''''''

    The ``moxie`` guest CPU support is deprecated and will be removed in
    a future version of QEMU. It's unclear whether anybody is still using
    CPU emulation in QEMU, and there are no test images available to make
    sure that the code is still working.

    ``lm32`` CPUs (since 5.2.0)
    '''''''''''''''''''''''''''

    The ``lm32`` guest CPU support is deprecated and will be removed in
    a future version of QEMU. The only public user of this architecture
    was the milkymist project, which has been dead for years; there was
    never an upstream Linux port.

    ``unicore32`` CPUs (since 5.2.0)
    ''''''''''''''''''''''''''''''''

    The ``unicore32`` guest CPU support is deprecated and will be removed in
    a future version of QEMU. Support for this CPU was removed from the
    upstream Linux kernel, and there is no available upstream toolchain
    to build binaries for it.

Robert Hoo:

    ``Icelake-Client`` CPU Model (since 5.2.0)
    ''''''''''''''''''''''''''''''''''''''''''

    ``Icelake-Client`` CPU Models are deprecated. Use ``Icelake-Server`` CPU
    Models instead.

Philippe Mathieu-Daudé:

    MIPS ``I7200`` CPU Model (since 5.2)
    ''''''''''''''''''''''''''''''''''''

    The ``I7200`` guest CPU relies on the nanoMIPS ISA, which is deprecated
    (the ISA has never been upstreamed to a compiler toolchain). Therefore
    this CPU is also deprecated.

    System emulator machines
    ------------------------

Philippe Mathieu-Daudé:

    Raspberry Pi ``raspi2`` and ``raspi3`` machines (since 5.2)
    '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    The Raspberry Pi machines come in various models (A, A+, B, B+). To be able
    to distinguish which model QEMU is implementing, the ``raspi2`` and ``raspi3``
    machines have been renamed ``raspi2b`` and ``raspi3b``.

    Device options
    --------------

    Emulated device options
    '''''''''''''''''''''''

Stefan Hajnoczi:

    ``-device virtio-blk,scsi=on|off`` (since 5.0.0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    The virtio-blk SCSI passthrough feature is a legacy VIRTIO feature.  VIRTIO 1.0
    and later do not support it because the virtio-scsi device was introduced for
    full SCSI support.  Use virtio-scsi instead when SCSI passthrough is required.

    Note this also applies to ``-device virtio-blk-pci,scsi=on|off``, which is an
    alias.

    Block device options
    ''''''''''''''''''''

Myself:

    ``"backing": ""`` (since 2.12.0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    In order to prevent QEMU from automatically opening an image's backing
    chain, use ``"backing": null`` instead.

Myself:

    ``rbd`` keyvalue pair encoded filenames: ``""`` (since 3.1.0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    Options for ``rbd`` should be specified according to its runtime options,
    like other block drivers.  Legacy parsing of keyvalue pair encoded
    filenames is useful to open images with the old format for backing files;
    These image files should be updated to use the current format.

    Example of legacy encoding::

      json:{"file.driver":"rbd", "file.filename":"rbd:rbd/name"}

    The above, converted to the current supported format::

      json:{"file.driver":"rbd", "file.pool":"rbd", "file.image":"name"}

Daniel P. Berrangé:

    ``sheepdog`` driver (since 5.2.0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    The ``sheepdog`` block device driver is deprecated. The corresponding upstream
    server project is no longer actively maintained. Users are recommended to switch
    to an alternative distributed block device driver such as RBD. The
    ``qemu-img convert`` command can be used to liberate existing data by moving
    it out of sheepdog volumes into an alternative storage backend.

    linux-user mode CPUs
    --------------------

Alex Bennée:

    ``ppc64abi32`` CPUs (since 5.2.0)
    '''''''''''''''''''''''''''''''''

    The ``ppc64abi32`` architecture has a number of issues which regularly
    trip up our CI testing and is suspected to be quite broken. For that
    reason the maintainers strongly suspect no one actually uses it.

    MIPS ``I7200`` CPU (since 5.2)
    ''''''''''''''''''''''''''''''

    The ``I7200`` guest CPU relies on the nanoMIPS ISA, which is deprecated
    (the ISA has never been upstreamed to a compiler toolchain). Therefore
    this CPU is also deprecated.

    Related binaries
    ----------------

Eric Blake:

    qemu-img amend to adjust backing file (since 5.1)
    '''''''''''''''''''''''''''''''''''''''''''''''''

    The use of ``qemu-img amend`` to modify the name or format of a qcow2
    backing image is deprecated; this functionality was never fully
    documented or tested, and interferes with other amend operations that
    need access to the original backing image (such as deciding whether a
    v3 zero cluster may be left unallocated when converting to a v2
    image).  Rather, any changes to the backing chain should be performed
    with ``qemu-img rebase -u`` either before or after the remaining
    changes being performed by amend, as appropriate.

    qemu-img backing file without format (since 5.1)
    ''''''''''''''''''''''''''''''''''''''''''''''''

    The use of ``qemu-img create``, ``qemu-img rebase``, or ``qemu-img
    convert`` to create or modify an image that depends on a backing file
    now recommends that an explicit backing format be provided.  This is
    for safety: if QEMU probes a different format than what you thought,
    the data presented to the guest will be corrupt; similarly, presenting
    a raw image to a guest allows a potential security exploit if a future
    probe sees a non-raw image based on guest writes.

    To avoid the warning message, or even future refusal to create an
    unsafe image, you must pass ``-o backing_fmt=`` (or the shorthand
    ``-F`` during create) to specify the intended backing format.  You may
    use ``qemu-img rebase -u`` to retroactively add a backing format to an
    existing image.  However, be aware that there are already potential
    security risks to blindly using ``qemu-img info`` to probe the format
    of an untrusted backing image, when deciding what format to add into
    an existing image.

    Backwards compatibility
    -----------------------

I'm not sure there's anything to remove here, but anyway, Peter Maydell:


    Runnability guarantee of CPU models (since 4.1.0)
    '''''''''''''''''''''''''''''''''''''''''''''''''

    Previous versions of QEMU never changed existing CPU models in
    ways that introduced additional host software or hardware
    requirements to the VM.  This allowed management software to
    safely change the machine type of an existing VM without
    introducing new requirements ("runnability guarantee").  This
    prevented CPU models from being updated to include CPU
    vulnerability mitigations, leaving guests vulnerable in the
    default configuration.

    The CPU model runnability guarantee won't apply anymore to
    existing CPU models.  Management software that needs runnability
    guarantees must resolve the CPU model aliases using the
    ``alias-of`` field returned by the ``query-cpu-definitions`` QMP
    command.

    While those guarantees are kept, the return value of
    ``query-cpu-definitions`` will have existing CPU model aliases
    point to a version that doesn't break runnability guarantees
    (specifically, version 1 of those CPU models).  In future QEMU
    versions, aliases will point to newer CPU model versions
    depending on the machine type, so management software must
    resolve CPU model aliases before starting a virtual machine.

    Guest Emulator ISAs
    -------------------

Philippe Mathieu-Daudé:

    nanoMIPS ISA
    ''''''''''''

    The ``nanoMIPS`` ISA has never been upstreamed to any compiler toolchain.
    As it is hard to generate binaries for it, declare it deprecated.



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
@ 2021-04-29 10:18 ` Gerd Hoffmann
  2021-04-29 10:24   ` Daniel P. Berrangé
  2021-04-29 10:25 ` Peter Maydell
                   ` (9 subsequent siblings)
  10 siblings, 1 reply; 33+ messages in thread
From: Gerd Hoffmann @ 2021-04-29 10:18 UTC (permalink / raw)
  To: Markus Armbruster
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Alex Bennée, qemu-devel, Robert Hoo, Alistair Francis,
	Stefan Hajnoczi, dirty.ice.hu, Philippe Mathieu-Daudé

  Hi,

>     ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
>     Creating sound card devices and vnc without ``audiodev=`` property (since 4.2)
>     Creating sound card devices using ``-soundhw`` (since 5.1)

I think these three should be dropped together, to minimize disruption.

Where do we strand in terms of libvirt support?  IIRC audiodev= support
in libvirt is rather recent (merged this year).  I'd tend to wait a bit
longer because of that.

Daniel?

take care,
  Gerd



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 10:18 ` Gerd Hoffmann
@ 2021-04-29 10:24   ` Daniel P. Berrangé
  2021-04-29 10:29     ` Peter Maydell
  0 siblings, 1 reply; 33+ messages in thread
From: Daniel P. Berrangé @ 2021-04-29 10:24 UTC (permalink / raw)
  To: Gerd Hoffmann
  Cc: Kevin Wolf, Thomas Huth, Alex Bennée, Markus Armbruster,
	qemu-devel, Alistair Francis, Stefan Hajnoczi, dirty.ice.hu,
	Robert Hoo, Philippe Mathieu-Daudé

On Thu, Apr 29, 2021 at 12:18:42PM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> >     ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
> >     Creating sound card devices and vnc without ``audiodev=`` property (since 4.2)
> >     Creating sound card devices using ``-soundhw`` (since 5.1)
> 
> I think these three should be dropped together, to minimize disruption.
> 
> Where do we strand in terms of libvirt support?  IIRC audiodev= support
> in libvirt is rather recent (merged this year).  I'd tend to wait a bit
> longer because of that.
> 
> Daniel?

Libvirt added supoort for -audio in 7.2.0, release April 4th, so only
one month ago.

If we drop the features in QEMU in this dev cycle though, this won't
impact most users until QEMU 6.1 releases in mid August. I'm perfectly
ok with people who use unreleased QEMU git master needing to update
their libvirt. The final release date is far enough away that distros
will have had new enough libvirt for a good while.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
  2021-04-29 10:18 ` Gerd Hoffmann
@ 2021-04-29 10:25 ` Peter Maydell
  2021-04-29 10:32 ` Daniel P. Berrangé
                   ` (8 subsequent siblings)
  10 siblings, 0 replies; 33+ messages in thread
From: Peter Maydell @ 2021-04-29 10:25 UTC (permalink / raw)
  To: Markus Armbruster
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Eduardo Habkost, Philippe Mathieu-Daudé,
	QEMU Developers, Robert Hoo, Alistair Francis, Gerd Hoffmann,
	Stefan Hajnoczi, Kővágó,
	Zoltán, Alex Bennée

On Thu, 29 Apr 2021 at 11:02, Markus Armbruster <armbru@redhat.com> wrote:
>
> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> is old enough to permit removal.  This is *not* a demand to remove, it's
> a polite request to consider whether the time for removal has come.
> Extra points for telling us in a reply.  "We should remove, but I can't
> do it myself right now" is a valid answer.  Let's review the file:

> I'm not sure there's anything to remove here, but anyway, Peter Maydell:

This isn't one of mine -- I just show up in git blame because this
section predates the conversion from texi to rst. It was originally
added by Eduardo (cc'd) in commit aa5b9692871.

>     Runnability guarantee of CPU models (since 4.1.0)
>     '''''''''''''''''''''''''''''''''''''''''''''''''
>
>     Previous versions of QEMU never changed existing CPU models in
>     ways that introduced additional host software or hardware
>     requirements to the VM.  This allowed management software to
>     safely change the machine type of an existing VM without
>     introducing new requirements ("runnability guarantee").  This
>     prevented CPU models from being updated to include CPU
>     vulnerability mitigations, leaving guests vulnerable in the
>     default configuration.
>
>     The CPU model runnability guarantee won't apply anymore to
>     existing CPU models.  Management software that needs runnability
>     guarantees must resolve the CPU model aliases using the
>     ``alias-of`` field returned by the ``query-cpu-definitions`` QMP
>     command.
>
>     While those guarantees are kept, the return value of
>     ``query-cpu-definitions`` will have existing CPU model aliases
>     point to a version that doesn't break runnability guarantees
>     (specifically, version 1 of those CPU models).  In future QEMU
>     versions, aliases will point to newer CPU model versions
>     depending on the machine type, so management software must
>     resolve CPU model aliases before starting a virtual machine.

thanks
-- PMM


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 10:24   ` Daniel P. Berrangé
@ 2021-04-29 10:29     ` Peter Maydell
  2021-04-29 10:35       ` Daniel P. Berrangé
  0 siblings, 1 reply; 33+ messages in thread
From: Peter Maydell @ 2021-04-29 10:29 UTC (permalink / raw)
  To: Daniel P. Berrangé
  Cc: Kevin Wolf, Thomas Huth, Philippe Mathieu-Daudé,
	QEMU Developers, Markus Armbruster, Alistair Francis,
	Gerd Hoffmann, Stefan Hajnoczi, Kővágó,
	Zoltán, Robert Hoo, Alex Bennée

On Thu, 29 Apr 2021 at 11:28, Daniel P. Berrangé <berrange@redhat.com> wrote:
>
> On Thu, Apr 29, 2021 at 12:18:42PM +0200, Gerd Hoffmann wrote:
> >   Hi,
> >
> > >     ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
> > >     Creating sound card devices and vnc without ``audiodev=`` property (since 4.2)
> > >     Creating sound card devices using ``-soundhw`` (since 5.1)
> >
> > I think these three should be dropped together, to minimize disruption.
> >
> > Where do we strand in terms of libvirt support?  IIRC audiodev= support
> > in libvirt is rather recent (merged this year).  I'd tend to wait a bit
> > longer because of that.
> >
> > Daniel?
>
> Libvirt added supoort for -audio in 7.2.0, release April 4th, so only
> one month ago.
>
> If we drop the features in QEMU in this dev cycle though, this won't
> impact most users until QEMU 6.1 releases in mid August. I'm perfectly
> ok with people who use unreleased QEMU git master needing to update
> their libvirt. The final release date is far enough away that distros
> will have had new enough libvirt for a good while.

It does feel to me that dropping the old options now would be being
a bit over-eager, though. The deprecation cycle time is a minimum, not
a target :-)

-- PMM


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
  2021-04-29 10:18 ` Gerd Hoffmann
  2021-04-29 10:25 ` Peter Maydell
@ 2021-04-29 10:32 ` Daniel P. Berrangé
  2021-04-30  6:47   ` Markus Armbruster
  2021-04-29 11:06 ` Paolo Bonzini
                   ` (7 subsequent siblings)
  10 siblings, 1 reply; 33+ messages in thread
From: Daniel P. Berrangé @ 2021-04-29 10:32 UTC (permalink / raw)
  To: Markus Armbruster
  Cc: Kevin Wolf, Thomas Huth, Alex Bennée, qemu-devel,
	Robert Hoo, Alistair Francis, Gerd Hoffmann, Stefan Hajnoczi,
	dirty.ice.hu, Philippe Mathieu-Daudé

On Thu, Apr 29, 2021 at 11:59:41AM +0200, Markus Armbruster wrote:
> Myself, but I only documented it; it's actually Kevin Wolf:
> 
>     ``blockdev-open-tray``, ``blockdev-close-tray`` argument ``device`` (since 2.8.0)
>     '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     Use argument ``id`` instead.
> 
>     ``eject`` argument ``device`` (since 2.8.0)
>     '''''''''''''''''''''''''''''''''''''''''''
> 
>     Use argument ``id`` instead.
> 
>     ``blockdev-change-medium`` argument ``device`` (since 2.8.0)
>     ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     Use argument ``id`` instead.
> 
>     ``block_set_io_throttle`` argument ``device`` (since 2.8.0)
>     '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     Use argument ``id`` instead.

FYI, I did prepare patches for these already, but they broke the iotests.

I found it difficult to figure out the right fix for the iotests, becuase
IIUC "device" and "id" values are different, and I didn't see what "id"
to use when args are still using -drive, not -blockdev.


> Myself:
> 
>     ``blockdev-add`` empty string argument ``backing`` (since 2.10.0)
>     '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     Use argument value ``null`` instead.
> 
> Myself, but I only documented it; it's actually Kevin Wolf:
> 
>     ``block-commit`` arguments ``base`` and ``top`` (since 3.1.0)
>     '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     Use arguments ``base-node`` and ``top-node`` instead.

I've also got patches that remove these two, but didn't submit them
as they were behind the patches for the "device" removal.



>     Block device options
>     ''''''''''''''''''''
> 
> Myself:
> 
>     ``"backing": ""`` (since 2.12.0)
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>     In order to prevent QEMU from automatically opening an image's backing
>     chain, use ``"backing": null`` instead.

Unless I'm mistaken,  this appeared to end up being a dupe of the
blockdev-add with empty string deprecation above.

> Myself:
> 
>     ``rbd`` keyvalue pair encoded filenames: ``""`` (since 3.1.0)
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>     Options for ``rbd`` should be specified according to its runtime options,
>     like other block drivers.  Legacy parsing of keyvalue pair encoded
>     filenames is useful to open images with the old format for backing files;
>     These image files should be updated to use the current format.
> 
>     Example of legacy encoding::
> 
>       json:{"file.driver":"rbd", "file.filename":"rbd:rbd/name"}
> 
>     The above, converted to the current supported format::
> 
>       json:{"file.driver":"rbd", "file.pool":"rbd", "file.image":"name"}

Got patch for this too

All my unsubmitted patches related to block are here:

  https://gitlab.com/berrange/qemu/-/commits/dep-block

NB I've not compile tested them recently since rebasing to git master.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 10:29     ` Peter Maydell
@ 2021-04-29 10:35       ` Daniel P. Berrangé
  2021-04-29 10:55         ` Gerd Hoffmann
  2021-04-29 11:07         ` Paolo Bonzini
  0 siblings, 2 replies; 33+ messages in thread
From: Daniel P. Berrangé @ 2021-04-29 10:35 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Kevin Wolf, Thomas Huth, Philippe Mathieu-Daudé,
	QEMU Developers, Markus Armbruster, Alistair Francis,
	Gerd Hoffmann, Stefan Hajnoczi, Kővágó,
	Zoltán, Robert Hoo, Alex Bennée

On Thu, Apr 29, 2021 at 11:29:42AM +0100, Peter Maydell wrote:
> On Thu, 29 Apr 2021 at 11:28, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > On Thu, Apr 29, 2021 at 12:18:42PM +0200, Gerd Hoffmann wrote:
> > >   Hi,
> > >
> > > >     ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
> > > >     Creating sound card devices and vnc without ``audiodev=`` property (since 4.2)
> > > >     Creating sound card devices using ``-soundhw`` (since 5.1)
> > >
> > > I think these three should be dropped together, to minimize disruption.
> > >
> > > Where do we strand in terms of libvirt support?  IIRC audiodev= support
> > > in libvirt is rather recent (merged this year).  I'd tend to wait a bit
> > > longer because of that.
> > >
> > > Daniel?
> >
> > Libvirt added supoort for -audio in 7.2.0, release April 4th, so only
> > one month ago.
> >
> > If we drop the features in QEMU in this dev cycle though, this won't
> > impact most users until QEMU 6.1 releases in mid August. I'm perfectly
> > ok with people who use unreleased QEMU git master needing to update
> > their libvirt. The final release date is far enough away that distros
> > will have had new enough libvirt for a good while.
> 
> It does feel to me that dropping the old options now would be being
> a bit over-eager, though. The deprecation cycle time is a minimum, not
> a target :-)

Note the QEMU since has been ready since 4.0, in April 2019 so 2 years.
We dropped the ball on getting this implemented in libvirt, since we
had almost no config options for sound at all in libvirt. We had just
hardcoded 3 sound backends based on the graphics frontend.

So in terms of historic libvirt compatibility, we've only ever relied
on the QEMU_AUDIODRIVER env, none of the other million audio env vars.

IOW, if QEMU was to be conservative, you can drop all env vars except
the main QEMU_AUDIODRIVER.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 10:35       ` Daniel P. Berrangé
@ 2021-04-29 10:55         ` Gerd Hoffmann
  2021-04-30 10:47           ` Markus Armbruster
  2021-04-29 11:07         ` Paolo Bonzini
  1 sibling, 1 reply; 33+ messages in thread
From: Gerd Hoffmann @ 2021-04-29 10:55 UTC (permalink / raw)
  To: Daniel P. Berrangé
  Cc: Kevin Wolf, Peter Maydell, Thomas Huth,
	Philippe Mathieu-Daudé,
	Markus Armbruster, QEMU Developers, Alistair Francis,
	Stefan Hajnoczi, Kővágó,
	Zoltán, Robert Hoo, Alex Bennée

  Hi,

> IOW, if QEMU was to be conservative, you can drop all env vars except
> the main QEMU_AUDIODRIVER.

As already mentioned above I want drop all legacy audio bits at once.

Leaving in the compatibility bits in for one or two more releases is
IMHO better than removing it partly now and the remaining bits in a
year.

take care,
  Gerd



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
                   ` (2 preceding siblings ...)
  2021-04-29 10:32 ` Daniel P. Berrangé
@ 2021-04-29 11:06 ` Paolo Bonzini
  2021-04-29 12:40   ` Gerd Hoffmann
  2021-04-29 11:17 ` Thomas Huth
                   ` (6 subsequent siblings)
  10 siblings, 1 reply; 33+ messages in thread
From: Paolo Bonzini @ 2021-04-29 11:06 UTC (permalink / raw)
  To: Markus Armbruster, qemu-devel
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Philippe Mathieu-Daudé,
	Robert Hoo, Alistair Francis, Gerd Hoffmann, Stefan Hajnoczi,
	dirty.ice.hu, Alex Bennée

On 29/04/21 11:59, Markus Armbruster wrote:
> Gerd Hoffmann:
> 
>      Creating sound card devices using ``-soundhw`` (since 5.1)
>      ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> 
>      Sound card devices should be created using ``-device`` instead.  The
>      names are the same for most devices.  The exceptions are ``hda`` which
>      needs two devices (``-device intel-hda -device hda-duplex``) and
>      ``pcspk`` which can be activated using ``-machine
>      pcspk-audiodev=<name>``.

For this to go away, I'd rather have something like the -nic option that 
provides an easy way to set up the front end and back end.

In other words you would do something like -audiohw 
<audiodev-args>,model=xxx and it gets desugared automatically to either

    -audiodev <audiodev-args>,id=foo -device devname,audiodev=xxx

or

    -audiodev <audiodev-args>,id=foo -M propname=foo

Paolo



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 10:35       ` Daniel P. Berrangé
  2021-04-29 10:55         ` Gerd Hoffmann
@ 2021-04-29 11:07         ` Paolo Bonzini
  1 sibling, 0 replies; 33+ messages in thread
From: Paolo Bonzini @ 2021-04-29 11:07 UTC (permalink / raw)
  To: Daniel P. Berrangé, Peter Maydell
  Cc: Kevin Wolf, Thomas Huth, Alex Bennée, QEMU Developers,
	Markus Armbruster, Alistair Francis, Gerd Hoffmann,
	Stefan Hajnoczi, Kővágó,
	Zoltán, Robert Hoo, Philippe Mathieu-Daudé

On 29/04/21 12:35, Daniel P. Berrangé wrote:
> Note the QEMU since has been ready since 4.0, in April 2019 so 2 years.
> We dropped the ball on getting this implemented in libvirt, since we
> had almost no config options for sound at all in libvirt. We had just
> hardcoded 3 sound backends based on the graphics frontend.
> 
> So in terms of historic libvirt compatibility, we've only ever relied
> on the QEMU_AUDIODRIVER env, none of the other million audio env vars.
> 
> IOW, if QEMU was to be conservative, you can drop all env vars except
> the main QEMU_AUDIODRIVER.

I like that, and keeping -soundhw as well until an audiodev-based 
replacement is there.

Paolo



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
                   ` (3 preceding siblings ...)
  2021-04-29 11:06 ` Paolo Bonzini
@ 2021-04-29 11:17 ` Thomas Huth
  2021-04-29 11:24   ` Peter Maydell
  2021-04-29 14:49 ` Stefan Hajnoczi
                   ` (5 subsequent siblings)
  10 siblings, 1 reply; 33+ messages in thread
From: Thomas Huth @ 2021-04-29 11:17 UTC (permalink / raw)
  To: Markus Armbruster, qemu-devel, Anthony Green
  Cc: Kevin Wolf, Daniel P. Berrangé,
	Alex Bennée, Robert Hoo, Alistair Francis, Gerd Hoffmann,
	Stefan Hajnoczi, dirty.ice.hu, Philippe Mathieu-Daudé

On 29/04/2021 11.59, Markus Armbruster wrote:
> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> is old enough to permit removal.  This is *not* a demand to remove, it's
> a polite request to consider whether the time for removal has come.
> Extra points for telling us in a reply.  "We should remove, but I can't
> do it myself right now" is a valid answer.  Let's review the file:
[...]
> Thomas Huth:
> 
>      ``moxie`` CPU (since 5.2.0)
>      '''''''''''''''''''''''''''
> 
>      The ``moxie`` guest CPU support is deprecated and will be removed in
>      a future version of QEMU. It's unclear whether anybody is still using
>      CPU emulation in QEMU, and there are no test images available to make
>      sure that the code is still working.

I'm fine with dropping moxie now - I've never seen anybody using it and I've 
never spotted any binaries in the internet that could still be used for 
regression testing of this target. And I've also put Anthony Green on CC: 
when I suggested the deprecation and he never replied. So I think it's 
really completely unused.

>      ``lm32`` CPUs (since 5.2.0)
>      '''''''''''''''''''''''''''
> 
>      The ``lm32`` guest CPU support is deprecated and will be removed in
>      a future version of QEMU. The only public user of this architecture
>      was the milkymist project, which has been dead for years; there was
>      never an upstream Linux port.
> 
>      ``unicore32`` CPUs (since 5.2.0)
>      ''''''''''''''''''''''''''''''''
> 
>      The ``unicore32`` guest CPU support is deprecated and will be removed in
>      a future version of QEMU. Support for this CPU was removed from the
>      upstream Linux kernel, and there is no available upstream toolchain
>      to build binaries for it.

I didn't add these two entries to the deprecation list, I just moved them 
around since they were in the wrong section. Both have been added by Peter 
instead (commit d8498005122 and 8e4ff4a8d2b)

  Thomas



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 11:17 ` Thomas Huth
@ 2021-04-29 11:24   ` Peter Maydell
  2021-05-03 10:39     ` Markus Armbruster
  0 siblings, 1 reply; 33+ messages in thread
From: Peter Maydell @ 2021-04-29 11:24 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Kevin Wolf, Daniel P. Berrangé, Philippe Mathieu-Daudé,
	Anthony Green, Markus Armbruster, QEMU Developers,
	Alistair Francis, Gerd Hoffmann, Stefan Hajnoczi,
	Kővágó,
	Zoltán, Robert Hoo, Alex Bennée

On Thu, 29 Apr 2021 at 12:19, Thomas Huth <thuth@redhat.com> wrote:
>
> On 29/04/2021 11.59, Markus Armbruster wrote:
> > If you're cc'ed, you added a section to docs/system/deprecated.rst that
> > is old enough to permit removal.  This is *not* a demand to remove, it's
> > a polite request to consider whether the time for removal has come.
> > Extra points for telling us in a reply.  "We should remove, but I can't
> > do it myself right now" is a valid answer.  Let's review the file:
> [...]
> > Thomas Huth:
> >
> >      ``moxie`` CPU (since 5.2.0)
> >      '''''''''''''''''''''''''''
> >
> >      The ``moxie`` guest CPU support is deprecated and will be removed in
> >      a future version of QEMU. It's unclear whether anybody is still using
> >      CPU emulation in QEMU, and there are no test images available to make
> >      sure that the code is still working.
>
> I'm fine with dropping moxie now - I've never seen anybody using it and I've
> never spotted any binaries in the internet that could still be used for
> regression testing of this target. And I've also put Anthony Green on CC:
> when I suggested the deprecation and he never replied. So I think it's
> really completely unused.
>
> >      ``lm32`` CPUs (since 5.2.0)
> >      '''''''''''''''''''''''''''
> >
> >      The ``lm32`` guest CPU support is deprecated and will be removed in
> >      a future version of QEMU. The only public user of this architecture
> >      was the milkymist project, which has been dead for years; there was
> >      never an upstream Linux port.
> >
> >      ``unicore32`` CPUs (since 5.2.0)
> >      ''''''''''''''''''''''''''''''''
> >
> >      The ``unicore32`` guest CPU support is deprecated and will be removed in
> >      a future version of QEMU. Support for this CPU was removed from the
> >      upstream Linux kernel, and there is no available upstream toolchain
> >      to build binaries for it.
>
> I didn't add these two entries to the deprecation list, I just moved them
> around since they were in the wrong section. Both have been added by Peter
> instead (commit d8498005122 and 8e4ff4a8d2b)

Yes, I think moxie, lm32 and unicore32 are all OK to drop now.

-- PMM


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 11:06 ` Paolo Bonzini
@ 2021-04-29 12:40   ` Gerd Hoffmann
  2021-04-29 13:12     ` Kevin Wolf
  2021-05-03 15:10     ` Paolo Bonzini
  0 siblings, 2 replies; 33+ messages in thread
From: Gerd Hoffmann @ 2021-04-29 12:40 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Philippe Mathieu-Daudé,
	Markus Armbruster, qemu-devel, Alistair Francis, Stefan Hajnoczi,
	dirty.ice.hu, Robert Hoo, Alex Bennée

  Hi,

> For this to go away, I'd rather have something like the -nic option that
> provides an easy way to set up the front end and back end.
> 
> In other words you would do something like -audiohw
> <audiodev-args>,model=xxx and it gets desugared automatically to either
> 
>    -audiodev <audiodev-args>,id=foo -device devname,audiodev=xxx
> 
> or
> 
>    -audiodev <audiodev-args>,id=foo -M propname=foo

Suggestions how to do that in a clean way?
Given that -audiodev is qapi-based I tried it this way:

--- a/qapi/audio.json
+++ b/qapi/audio.json
@@ -419,3 +419,22 @@
     'sdl':       'AudiodevSdlOptions',
     'spice':     'AudiodevGenericOptions',
     'wav':       'AudiodevWavOptions' } }
+
+##
+# @AudioDevice:
+#
+# TODO
+##
+{ 'enum': 'AudioDevice',
+  'data': [ 'pcspk', 'ac97', 'hda' ] }
+
+##
+# @AudioConfig:
+#
+# TODO
+##
+{ 'struct': 'AudioConfig',
+  'base': 'Audiodev',
+  'data': {
+    'model': 'AudioDevice'
+}}

But qemu doesn't like the schema:
qapi/audio.json: In struct 'AudioConfig':
qapi/audio.json:436: 'base' requires a struct type, union type 'Audiodev' isn't

We could easily support the case that no additional options are
specified, like this:

+{ 'struct': 'AudioConfig',
+  'data': {
+    'driver': 'AudiodevDriver',
+    'model': 'AudioDevice'
+}}

But then you have to switch to the long form as soon as you want
specify any audiodev config option.  Maybe that is ok, dunno how
much configuration options -nic supports.

take care,
  Gerd



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 12:40   ` Gerd Hoffmann
@ 2021-04-29 13:12     ` Kevin Wolf
  2021-04-29 13:46       ` Gerd Hoffmann
  2021-05-03 15:10     ` Paolo Bonzini
  1 sibling, 1 reply; 33+ messages in thread
From: Kevin Wolf @ 2021-04-29 13:12 UTC (permalink / raw)
  To: Gerd Hoffmann
  Cc: Thomas Huth, Daniel P. Berrangé, Philippe Mathieu-Daudé,
	Markus Armbruster, qemu-devel, Alistair Francis, Stefan Hajnoczi,
	dirty.ice.hu, Paolo Bonzini, Robert Hoo, Alex Bennée

Am 29.04.2021 um 14:40 hat Gerd Hoffmann geschrieben:
>   Hi,
> 
> > For this to go away, I'd rather have something like the -nic option that
> > provides an easy way to set up the front end and back end.
> > 
> > In other words you would do something like -audiohw
> > <audiodev-args>,model=xxx and it gets desugared automatically to either
> > 
> >    -audiodev <audiodev-args>,id=foo -device devname,audiodev=xxx
> > 
> > or
> > 
> >    -audiodev <audiodev-args>,id=foo -M propname=foo
> 
> Suggestions how to do that in a clean way?
> Given that -audiodev is qapi-based I tried it this way:
> 
> --- a/qapi/audio.json
> +++ b/qapi/audio.json
> @@ -419,3 +419,22 @@
>      'sdl':       'AudiodevSdlOptions',
>      'spice':     'AudiodevGenericOptions',
>      'wav':       'AudiodevWavOptions' } }
> +
> +##
> +# @AudioDevice:
> +#
> +# TODO
> +##
> +{ 'enum': 'AudioDevice',
> +  'data': [ 'pcspk', 'ac97', 'hda' ] }
> +
> +##
> +# @AudioConfig:
> +#
> +# TODO
> +##
> +{ 'struct': 'AudioConfig',
> +  'base': 'Audiodev',
> +  'data': {
> +    'model': 'AudioDevice'
> +}}
> 
> But qemu doesn't like the schema:
> qapi/audio.json: In struct 'AudioConfig':
> qapi/audio.json:436: 'base' requires a struct type, union type 'Audiodev' isn't
> 
> We could easily support the case that no additional options are
> specified, like this:
> 
> +{ 'struct': 'AudioConfig',
> +  'data': {
> +    'driver': 'AudiodevDriver',
> +    'model': 'AudioDevice'
> +}}
> 
> But then you have to switch to the long form as soon as you want
> specify any audiodev config option.  Maybe that is ok, dunno how
> much configuration options -nic supports.

Good support for this in QAPI sounds hard because you will want to use
the same Audiodev C type for both options. I think the naive
implementation for using unions as a base would end up creating new
C types.

Another option might be that you just nest things:

{ 'struct': 'AudioConfig',
  'data': {
      'model': 'AudioDevice',
      'backend': 'Audiodev' } }

Possibly instead of 'model' on the top level, you'll actually want to
nest there, too, and accept device properties.

If or when I finally get QAPI aliases merged, we can make this look nice
on the command line again by simply mapping everything to the top level
so that you don't necessarily need to use dotted keys like you would
initially, e.g. -audio backend.driver=sdl,model=hda could be optionally
reduced to -audio driver=sdl,model=hda.

Kevin



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 13:12     ` Kevin Wolf
@ 2021-04-29 13:46       ` Gerd Hoffmann
  2021-04-29 15:05         ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 33+ messages in thread
From: Gerd Hoffmann @ 2021-04-29 13:46 UTC (permalink / raw)
  To: Kevin Wolf
  Cc: Thomas Huth, Daniel P. Berrangé, Philippe Mathieu-Daudé,
	Markus Armbruster, qemu-devel, Alistair Francis, Stefan Hajnoczi,
	dirty.ice.hu, Paolo Bonzini, Robert Hoo, Alex Bennée

  Hi,

> Another option might be that you just nest things:
> 
> { 'struct': 'AudioConfig',
>   'data': {
>       'model': 'AudioDevice',
>       'backend': 'Audiodev' } }
> 
> Possibly instead of 'model' on the top level, you'll actually want to
> nest there, too, and accept device properties.

Hmm.  Not so easy I suspect.  While most sound cards map to a single
device there are exceptions.  pcspk is build-in and hda is two devices.

Where do we stand in terms of QAPI support for -device btw?

> If or when I finally get QAPI aliases merged, we can make this look nice
> on the command line again by simply mapping everything to the top level
> so that you don't necessarily need to use dotted keys like you would
> initially, e.g. -audio backend.driver=sdl,model=hda could be optionally
> reduced to -audio driver=sdl,model=hda.

Yes, with aliasing available this would be a reasonable option.

take care,
  Gerd



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
                   ` (4 preceding siblings ...)
  2021-04-29 11:17 ` Thomas Huth
@ 2021-04-29 14:49 ` Stefan Hajnoczi
  2021-04-29 16:32 ` Eduardo Habkost
                   ` (4 subsequent siblings)
  10 siblings, 0 replies; 33+ messages in thread
From: Stefan Hajnoczi @ 2021-04-29 14:49 UTC (permalink / raw)
  To: Markus Armbruster
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Alex Bennée, qemu-devel, Robert Hoo, Alistair Francis,
	Gerd Hoffmann, dirty.ice.hu, Philippe Mathieu-Daudé

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

On Thu, Apr 29, 2021 at 11:59:41AM +0200, Markus Armbruster wrote:
> Stefan Hajnoczi:
> 
>     ``-device virtio-blk,scsi=on|off`` (since 5.0.0)
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>     The virtio-blk SCSI passthrough feature is a legacy VIRTIO feature.  VIRTIO 1.0
>     and later do not support it because the virtio-scsi device was introduced for
>     full SCSI support.  Use virtio-scsi instead when SCSI passthrough is required.
> 
>     Note this also applies to ``-device virtio-blk-pci,scsi=on|off``, which is an
>     alias.

Thanks for sending this reminder!

I'm writing a patch to remove this and if nothing breaks I'll send it
for QEMU 6.1.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 13:46       ` Gerd Hoffmann
@ 2021-04-29 15:05         ` Philippe Mathieu-Daudé
  2021-04-30  7:01           ` Markus Armbruster
  2021-04-30  7:01           ` Gerd Hoffmann
  0 siblings, 2 replies; 33+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-04-29 15:05 UTC (permalink / raw)
  To: Gerd Hoffmann, Kevin Wolf
  Cc: Thomas Huth, Daniel P. Berrangé,
	Markus Armbruster, qemu-devel, Alistair Francis, Stefan Hajnoczi,
	dirty.ice.hu, Paolo Bonzini, Robert Hoo, Alex Bennée

On 4/29/21 3:46 PM, Gerd Hoffmann wrote:

> Hmm.  Not so easy I suspect.  While most sound cards map to a single
> device there are exceptions.  pcspk is build-in and hda is two devices.

What do you mean by "pcspk is build-in"?

Do you mean "the 'pcspk' audiodev is build in the 8254 PIT device"?
(see pcspk_audio_init).

FWIW I'm using this device as example to work on the PWM API,
and I see the AUD API as a generic DSP processing one.
And in my TODO I have "split pcspk audiodev backend from 8254".


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
                   ` (5 preceding siblings ...)
  2021-04-29 14:49 ` Stefan Hajnoczi
@ 2021-04-29 16:32 ` Eduardo Habkost
  2021-04-30  3:22 ` Robert Hoo
                   ` (3 subsequent siblings)
  10 siblings, 0 replies; 33+ messages in thread
From: Eduardo Habkost @ 2021-04-29 16:32 UTC (permalink / raw)
  To: Markus Armbruster
  Cc: Igor Mammedov, Jiri Denemark, Daniel P. Berrange, qemu-devel

+Jiri, +Daniel, +Igor

On Thu, Apr 29, 2021 at 11:59:41AM +0200, Markus Armbruster wrote:
[...]
> I'm not sure there's anything to remove here, but anyway, Peter Maydell:
> 

This one is mine.

There's no code to remove, but the intention is to eventually
change default_cpu_version to CPU_VERSION_LATEST on newer machine
types.

> 
>     Runnability guarantee of CPU models (since 4.1.0)
>     '''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     Previous versions of QEMU never changed existing CPU models in
>     ways that introduced additional host software or hardware
>     requirements to the VM.  This allowed management software to
>     safely change the machine type of an existing VM without
>     introducing new requirements ("runnability guarantee").  This
>     prevented CPU models from being updated to include CPU
>     vulnerability mitigations, leaving guests vulnerable in the
>     default configuration.
> 
>     The CPU model runnability guarantee won't apply anymore to
>     existing CPU models.  Management software that needs runnability
>     guarantees must resolve the CPU model aliases using the
>     ``alias-of`` field returned by the ``query-cpu-definitions`` QMP
>     command.
> 
>     While those guarantees are kept, the return value of
>     ``query-cpu-definitions`` will have existing CPU model aliases
>     point to a version that doesn't break runnability guarantees
>     (specifically, version 1 of those CPU models).  In future QEMU
>     versions, aliases will point to newer CPU model versions
>     depending on the machine type, so management software must
>     resolve CPU model aliases before starting a virtual machine.

libvirt had no time to adapt to this yet.  As far as I
understand, they need the following series to be merged first so
they can more easily resolve the unversioned CPU model name
aliases:

https://lore.kernel.org/qemu-devel/20201013230457.150630-1-ehabkost@redhat.com

I need to rebase that series and resubmit.

-- 
Eduardo



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
                   ` (6 preceding siblings ...)
  2021-04-29 16:32 ` Eduardo Habkost
@ 2021-04-30  3:22 ` Robert Hoo
  2021-05-03  1:41 ` Alistair Francis
                   ` (2 subsequent siblings)
  10 siblings, 0 replies; 33+ messages in thread
From: Robert Hoo @ 2021-04-30  3:22 UTC (permalink / raw)
  To: Markus Armbruster, qemu-devel
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Alex Bennée, Alistair Francis, Gerd Hoffmann,
	Stefan Hajnoczi, dirty.ice.hu, Philippe Mathieu-Daudé

On Thu, 2021-04-29 at 11:59 +0200, Markus Armbruster wrote:
> If you're cc'ed, you added a section to docs/system/deprecated.rst
> that
> is old enough to permit removal.  This is *not* a demand to remove,
> it's
> a polite request to consider whether the time for removal has come.
> Extra points for telling us in a reply.  "We should remove, but I
> can't
> do it myself right now" is a valid answer.  Let's review the file:
> 
>     System emulator command line arguments
>     --------------------------------------
> 
[...]
> 
> Robert Hoo:
> 
>     ``Icelake-Client`` CPU Model (since 5.2.0)
>     ''''''''''''''''''''''''''''''''''''''''''
> 
>     ``Icelake-Client`` CPU Models are deprecated. Use ``Icelake-
> Server`` CPU
>     Models instead.
> 
Yeah, please drop this entry.
Actually I've sent patches for this.
https://lore.kernel.org/qemu-devel/1619660147-136679-1-git-send-email-robert.hu@linux.intel.com/



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 10:32 ` Daniel P. Berrangé
@ 2021-04-30  6:47   ` Markus Armbruster
  0 siblings, 0 replies; 33+ messages in thread
From: Markus Armbruster @ 2021-04-30  6:47 UTC (permalink / raw)
  To: Daniel P. Berrangé
  Cc: Kevin Wolf, Thomas Huth, Philippe Mathieu-Daudé,
	qemu-devel, Robert Hoo, Alistair Francis, Gerd Hoffmann,
	Stefan Hajnoczi, dirty.ice.hu, Alex Bennée

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, Apr 29, 2021 at 11:59:41AM +0200, Markus Armbruster wrote:
>> Myself, but I only documented it; it's actually Kevin Wolf:
>> 
>>     ``blockdev-open-tray``, ``blockdev-close-tray`` argument ``device`` (since 2.8.0)
>>     '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>> 
>>     Use argument ``id`` instead.
>> 
>>     ``eject`` argument ``device`` (since 2.8.0)
>>     '''''''''''''''''''''''''''''''''''''''''''
>> 
>>     Use argument ``id`` instead.
>> 
>>     ``blockdev-change-medium`` argument ``device`` (since 2.8.0)
>>     ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>> 
>>     Use argument ``id`` instead.
>> 
>>     ``block_set_io_throttle`` argument ``device`` (since 2.8.0)
>>     '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>> 
>>     Use argument ``id`` instead.
>
> FYI, I did prepare patches for these already, but they broke the iotests.
>
> I found it difficult to figure out the right fix for the iotests, becuase
> IIUC "device" and "id" values are different, and I didn't see what "id"
> to use when args are still using -drive, not -blockdev.

Rebase and post as RFC to solicit clues or even fixes?

[...]



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 15:05         ` Philippe Mathieu-Daudé
@ 2021-04-30  7:01           ` Markus Armbruster
  2021-04-30  7:01           ` Gerd Hoffmann
  1 sibling, 0 replies; 33+ messages in thread
From: Markus Armbruster @ 2021-04-30  7:01 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	qemu-devel, Robert Hoo, Alistair Francis, Gerd Hoffmann,
	Stefan Hajnoczi, dirty.ice.hu, Paolo Bonzini, Alex Bennée

Philippe Mathieu-Daudé <f4bug@amsat.org> writes:

> On 4/29/21 3:46 PM, Gerd Hoffmann wrote:
>
>> Hmm.  Not so easy I suspect.  While most sound cards map to a single
>> device there are exceptions.  pcspk is build-in and hda is two devices.
>
> What do you mean by "pcspk is build-in"?
>
> Do you mean "the 'pcspk' audiodev is build in the 8254 PIT device"?
> (see pcspk_audio_init).

I think so.  The 8254 is an onboard device, i.e. it's always there.  In
real PC hardware, one of its timers is wired to a speaker.  In our
virtual hardware, we have separate "isa-pit" (or "kvm-pit) and
"isa-pcspk" devices, where the latter connects to the former via link
property "pit", and may be connected to an audio backend, but isn't by
default.  To connect to one, use -machine pcspk-audiodev=...

> FWIW I'm using this device as example to work on the PWM API,
> and I see the AUD API as a generic DSP processing one.
> And in my TODO I have "split pcspk audiodev backend from 8254".

Not sure I understand your TODO, but then I don't have to :)



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 15:05         ` Philippe Mathieu-Daudé
  2021-04-30  7:01           ` Markus Armbruster
@ 2021-04-30  7:01           ` Gerd Hoffmann
  1 sibling, 0 replies; 33+ messages in thread
From: Gerd Hoffmann @ 2021-04-30  7:01 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Markus Armbruster, qemu-devel, Alistair Francis, Stefan Hajnoczi,
	dirty.ice.hu, Paolo Bonzini, Robert Hoo, Alex Bennée

On Thu, Apr 29, 2021 at 05:05:35PM +0200, Philippe Mathieu-Daudé wrote:
> On 4/29/21 3:46 PM, Gerd Hoffmann wrote:
> 
> > Hmm.  Not so easy I suspect.  While most sound cards map to a single
> > device there are exceptions.  pcspk is build-in and hda is two devices.
> 
> What do you mean by "pcspk is build-in"?
> 
> Do you mean "the 'pcspk' audiodev is build in the 8254 PIT device"?
> (see pcspk_audio_init).

built-in == "the device is there, no matter what".  Being part of 8254
PIT is the underlying technical reason for that.  The only thing you can
do when configuring qemu is assigning an audio backend to it (or not).

take care,
  Gerd



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 10:55         ` Gerd Hoffmann
@ 2021-04-30 10:47           ` Markus Armbruster
  0 siblings, 0 replies; 33+ messages in thread
From: Markus Armbruster @ 2021-04-30 10:47 UTC (permalink / raw)
  To: Gerd Hoffmann
  Cc: Kevin Wolf, Peter Maydell, Thomas Huth, Daniel P. Berrangé,
	Alex Bennée, QEMU Developers, Robert Hoo, Alistair Francis,
	Stefan Hajnoczi, dirty.ice.hu, Philippe Mathieu-Daudé

Gerd Hoffmann <kraxel@redhat.com> writes:

>   Hi,
>
>> IOW, if QEMU was to be conservative, you can drop all env vars except
>> the main QEMU_AUDIODRIVER.
>
> As already mentioned above I want drop all legacy audio bits at once.
>
> Leaving in the compatibility bits in for one or two more releases is
> IMHO better than removing it partly now and the remaining bits in a
> year.

The message starting this thread was a "polite request to consider
whether the time for removal has come."  "Not now" is a perfectly fine
answer.  Thanks!



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
                   ` (7 preceding siblings ...)
  2021-04-30  3:22 ` Robert Hoo
@ 2021-05-03  1:41 ` Alistair Francis
  2021-05-03  4:49   ` Thomas Huth
  2021-05-03 13:14 ` Philippe Mathieu-Daudé
  2021-05-03 18:21 ` Eric Blake
  10 siblings, 1 reply; 33+ messages in thread
From: Alistair Francis @ 2021-05-03  1:41 UTC (permalink / raw)
  To: Markus Armbruster
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Philippe Mathieu-Daudé,
	qemu-devel@nongnu.org Developers, Robert Hoo, Alistair Francis,
	Gerd Hoffmann, Stefan Hajnoczi, dirty.ice.hu, Alex Bennée

On Thu, Apr 29, 2021 at 8:00 PM Markus Armbruster <armbru@redhat.com> wrote:
>
> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> is old enough to permit removal.  This is *not* a demand to remove, it's
> a polite request to consider whether the time for removal has come.
> Extra points for telling us in a reply.  "We should remove, but I can't
> do it myself right now" is a valid answer.  Let's review the file:
>
>     System emulator command line arguments
>     --------------------------------------
>
> Kővágó, Zoltán:
>
>     ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
>     '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>
>     The ``-audiodev`` argument is now the preferred way to specify audio
>     backend settings instead of environment variables.  To ease migration to
>     the new format, the ``-audiodev-help`` option can be used to convert
>     the current values of the environment variables to ``-audiodev`` options.
>
> Kővágó, Zoltán:
>
>     Creating sound card devices and vnc without ``audiodev=`` property (since 4.2)
>     ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>
>     When not using the deprecated legacy audio config, each sound card
>     should specify an ``audiodev=`` property.  Additionally, when using
>     vnc, you should specify an ``audiodev=`` property if you plan to
>     transmit audio through the VNC protocol.
>
> Gerd Hoffmann:
>
>     Creating sound card devices using ``-soundhw`` (since 5.1)
>     ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>
>     Sound card devices should be created using ``-device`` instead.  The
>     names are the same for most devices.  The exceptions are ``hda`` which
>     needs two devices (``-device intel-hda -device hda-duplex``) and
>     ``pcspk`` which can be activated using ``-machine
>     pcspk-audiodev=<name>``.
>
> [...]
>
> Alistair Francis:
>
>     RISC-V ``-bios`` (since 5.1)
>     ''''''''''''''''''''''''''''
>
>     QEMU 4.1 introduced support for the -bios option in QEMU for RISC-V for the
>     RISC-V virt machine and sifive_u machine. QEMU 4.1 had no changes to the
>     default behaviour to avoid breakages.
>
>     QEMU 5.1 changes the default behaviour from ``-bios none`` to ``-bios default``.
>
>     QEMU 5.1 has three options:
>      1. ``-bios default`` - This is the current default behavior if no -bios option
>           is included. This option will load the default OpenSBI firmware automatically.
>           The firmware is included with the QEMU release and no user interaction is
>           required. All a user needs to do is specify the kernel they want to boot
>           with the -kernel option
>      2. ``-bios none`` - QEMU will not automatically load any firmware. It is up
>           to the user to load all the images they need.
>      3. ``-bios <file>`` - Tells QEMU to load the specified file as the firmwrae.
>

This has already been acted upon in the code, we now default to
including a "bios" with RISC-V softmmu which is what this is
describing.

Do we need to take any action to indicate that it's already in effect?

Alistair


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-05-03  1:41 ` Alistair Francis
@ 2021-05-03  4:49   ` Thomas Huth
  2021-05-03  7:12     ` Alistair Francis
  0 siblings, 1 reply; 33+ messages in thread
From: Thomas Huth @ 2021-05-03  4:49 UTC (permalink / raw)
  To: Alistair Francis, Markus Armbruster
  Cc: Kevin Wolf, Daniel P. Berrangé, Philippe Mathieu-Daudé,
	qemu-devel@nongnu.org Developers, Robert Hoo, Alistair Francis,
	Gerd Hoffmann, Stefan Hajnoczi, dirty.ice.hu, Alex Bennée

On 03/05/2021 03.41, Alistair Francis wrote:
> On Thu, Apr 29, 2021 at 8:00 PM Markus Armbruster <armbru@redhat.com> wrote:
>>
>> If you're cc'ed, you added a section to docs/system/deprecated.rst that
>> is old enough to permit removal.  This is *not* a demand to remove, it's
>> a polite request to consider whether the time for removal has come.
>> Extra points for telling us in a reply.  "We should remove, but I can't
>> do it myself right now" is a valid answer.  Let's review the file:
>>
>>      System emulator command line arguments
>>      --------------------------------------
>>
>> Kővágó, Zoltán:
>>
>>      ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
>>      '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>>
>>      The ``-audiodev`` argument is now the preferred way to specify audio
>>      backend settings instead of environment variables.  To ease migration to
>>      the new format, the ``-audiodev-help`` option can be used to convert
>>      the current values of the environment variables to ``-audiodev`` options.
>>
>> Kővágó, Zoltán:
>>
>>      Creating sound card devices and vnc without ``audiodev=`` property (since 4.2)
>>      ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>>
>>      When not using the deprecated legacy audio config, each sound card
>>      should specify an ``audiodev=`` property.  Additionally, when using
>>      vnc, you should specify an ``audiodev=`` property if you plan to
>>      transmit audio through the VNC protocol.
>>
>> Gerd Hoffmann:
>>
>>      Creating sound card devices using ``-soundhw`` (since 5.1)
>>      ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>>
>>      Sound card devices should be created using ``-device`` instead.  The
>>      names are the same for most devices.  The exceptions are ``hda`` which
>>      needs two devices (``-device intel-hda -device hda-duplex``) and
>>      ``pcspk`` which can be activated using ``-machine
>>      pcspk-audiodev=<name>``.
>>
>> [...]
>>
>> Alistair Francis:
>>
>>      RISC-V ``-bios`` (since 5.1)
>>      ''''''''''''''''''''''''''''
>>
>>      QEMU 4.1 introduced support for the -bios option in QEMU for RISC-V for the
>>      RISC-V virt machine and sifive_u machine. QEMU 4.1 had no changes to the
>>      default behaviour to avoid breakages.
>>
>>      QEMU 5.1 changes the default behaviour from ``-bios none`` to ``-bios default``.
>>
>>      QEMU 5.1 has three options:
>>       1. ``-bios default`` - This is the current default behavior if no -bios option
>>            is included. This option will load the default OpenSBI firmware automatically.
>>            The firmware is included with the QEMU release and no user interaction is
>>            required. All a user needs to do is specify the kernel they want to boot
>>            with the -kernel option
>>       2. ``-bios none`` - QEMU will not automatically load any firmware. It is up
>>            to the user to load all the images they need.
>>       3. ``-bios <file>`` - Tells QEMU to load the specified file as the firmwrae.
>>
> 
> This has already been acted upon in the code, we now default to
> including a "bios" with RISC-V softmmu which is what this is
> describing.
> 
> Do we need to take any action to indicate that it's already in effect?

deprecated.rst is mainly thought for the things that only have been marked 
as deprecated, but not changed yet. Once it's done, the items normally get 
moved to docs/system/removed-features.rst instead.

  Thomas



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-05-03  4:49   ` Thomas Huth
@ 2021-05-03  7:12     ` Alistair Francis
  2021-05-03 15:13       ` Paolo Bonzini
  0 siblings, 1 reply; 33+ messages in thread
From: Alistair Francis @ 2021-05-03  7:12 UTC (permalink / raw)
  To: Thomas Huth
  Cc: Kevin Wolf, Daniel P. Berrangé,
	qemu-devel@nongnu.org Developers, Philippe Mathieu-Daudé,
	Markus Armbruster, Robert Hoo, Alistair Francis, Gerd Hoffmann,
	Stefan Hajnoczi, dirty.ice.hu, Alex Bennée

On Mon, May 3, 2021 at 2:49 PM Thomas Huth <thuth@redhat.com> wrote:
>
> On 03/05/2021 03.41, Alistair Francis wrote:
> > On Thu, Apr 29, 2021 at 8:00 PM Markus Armbruster <armbru@redhat.com> wrote:
> >>
> >> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> >> is old enough to permit removal.  This is *not* a demand to remove, it's
> >> a polite request to consider whether the time for removal has come.
> >> Extra points for telling us in a reply.  "We should remove, but I can't
> >> do it myself right now" is a valid answer.  Let's review the file:
> >>
> >>      System emulator command line arguments
> >>      --------------------------------------
> >>
> >> Kővágó, Zoltán:
> >>
> >>      ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
> >>      '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> >>
> >>      The ``-audiodev`` argument is now the preferred way to specify audio
> >>      backend settings instead of environment variables.  To ease migration to
> >>      the new format, the ``-audiodev-help`` option can be used to convert
> >>      the current values of the environment variables to ``-audiodev`` options.
> >>
> >> Kővágó, Zoltán:
> >>
> >>      Creating sound card devices and vnc without ``audiodev=`` property (since 4.2)
> >>      ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> >>
> >>      When not using the deprecated legacy audio config, each sound card
> >>      should specify an ``audiodev=`` property.  Additionally, when using
> >>      vnc, you should specify an ``audiodev=`` property if you plan to
> >>      transmit audio through the VNC protocol.
> >>
> >> Gerd Hoffmann:
> >>
> >>      Creating sound card devices using ``-soundhw`` (since 5.1)
> >>      ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> >>
> >>      Sound card devices should be created using ``-device`` instead.  The
> >>      names are the same for most devices.  The exceptions are ``hda`` which
> >>      needs two devices (``-device intel-hda -device hda-duplex``) and
> >>      ``pcspk`` which can be activated using ``-machine
> >>      pcspk-audiodev=<name>``.
> >>
> >> [...]
> >>
> >> Alistair Francis:
> >>
> >>      RISC-V ``-bios`` (since 5.1)
> >>      ''''''''''''''''''''''''''''
> >>
> >>      QEMU 4.1 introduced support for the -bios option in QEMU for RISC-V for the
> >>      RISC-V virt machine and sifive_u machine. QEMU 4.1 had no changes to the
> >>      default behaviour to avoid breakages.
> >>
> >>      QEMU 5.1 changes the default behaviour from ``-bios none`` to ``-bios default``.
> >>
> >>      QEMU 5.1 has three options:
> >>       1. ``-bios default`` - This is the current default behavior if no -bios option
> >>            is included. This option will load the default OpenSBI firmware automatically.
> >>            The firmware is included with the QEMU release and no user interaction is
> >>            required. All a user needs to do is specify the kernel they want to boot
> >>            with the -kernel option
> >>       2. ``-bios none`` - QEMU will not automatically load any firmware. It is up
> >>            to the user to load all the images they need.
> >>       3. ``-bios <file>`` - Tells QEMU to load the specified file as the firmwrae.
> >>
> >
> > This has already been acted upon in the code, we now default to
> > including a "bios" with RISC-V softmmu which is what this is
> > describing.
> >
> > Do we need to take any action to indicate that it's already in effect?
>
> deprecated.rst is mainly thought for the things that only have been marked
> as deprecated, but not changed yet. Once it's done, the items normally get
> moved to docs/system/removed-features.rst instead.

Too easy, I'll move it there instead.

Alistair

>
>   Thomas
>


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 11:24   ` Peter Maydell
@ 2021-05-03 10:39     ` Markus Armbruster
  0 siblings, 0 replies; 33+ messages in thread
From: Markus Armbruster @ 2021-05-03 10:39 UTC (permalink / raw)
  To: Peter Maydell
  Cc: Kevin Wolf, Thomas Huth, Daniel P.Berrangé,
	Alex Bennée, Anthony Green, Markus Armbruster,
	QEMU Developers, Alistair Francis, Gerd Hoffmann,
	Stefan Hajnoczi, dirty.ice.hu, Robert Hoo,
	Philippe Mathieu-Daudé

Peter Maydell <peter.maydell@linaro.org> writes:

> On Thu, 29 Apr 2021 at 12:19, Thomas Huth <thuth@redhat.com> wrote:
>>
>> On 29/04/2021 11.59, Markus Armbruster wrote:
>> > If you're cc'ed, you added a section to docs/system/deprecated.rst that
>> > is old enough to permit removal.  This is *not* a demand to remove, it's
>> > a polite request to consider whether the time for removal has come.
>> > Extra points for telling us in a reply.  "We should remove, but I can't
>> > do it myself right now" is a valid answer.  Let's review the file:
>> [...]
>> > Thomas Huth:
>> >
>> >      ``moxie`` CPU (since 5.2.0)
>> >      '''''''''''''''''''''''''''
>> >
>> >      The ``moxie`` guest CPU support is deprecated and will be removed in
>> >      a future version of QEMU. It's unclear whether anybody is still using
>> >      CPU emulation in QEMU, and there are no test images available to make
>> >      sure that the code is still working.
>>
>> I'm fine with dropping moxie now - I've never seen anybody using it and I've
>> never spotted any binaries in the internet that could still be used for
>> regression testing of this target. And I've also put Anthony Green on CC:
>> when I suggested the deprecation and he never replied. So I think it's
>> really completely unused.
>>
>> >      ``lm32`` CPUs (since 5.2.0)
>> >      '''''''''''''''''''''''''''
>> >
>> >      The ``lm32`` guest CPU support is deprecated and will be removed in
>> >      a future version of QEMU. The only public user of this architecture
>> >      was the milkymist project, which has been dead for years; there was
>> >      never an upstream Linux port.
>> >
>> >      ``unicore32`` CPUs (since 5.2.0)
>> >      ''''''''''''''''''''''''''''''''
>> >
>> >      The ``unicore32`` guest CPU support is deprecated and will be removed in
>> >      a future version of QEMU. Support for this CPU was removed from the
>> >      upstream Linux kernel, and there is no available upstream toolchain
>> >      to build binaries for it.
>>
>> I didn't add these two entries to the deprecation list, I just moved them
>> around since they were in the wrong section. Both have been added by Peter
>> instead (commit d8498005122 and 8e4ff4a8d2b)
>
> Yes, I think moxie, lm32 and unicore32 are all OK to drop now.

Done:

    [PATCH] Remove the deprecated moxie target
    Message-Id: <20210430160355.698194-1-thuth@redhat.com>

    [PATCH 0/2] Drop deprecated lm32 and unicore32
    Message-Id: <20210503084034.3804963-1-armbru@redhat.com>



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
                   ` (8 preceding siblings ...)
  2021-05-03  1:41 ` Alistair Francis
@ 2021-05-03 13:14 ` Philippe Mathieu-Daudé
  2021-05-03 18:21 ` Eric Blake
  10 siblings, 0 replies; 33+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-05-03 13:14 UTC (permalink / raw)
  To: Markus Armbruster, qemu-devel
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Robert Hoo, Alistair Francis, Gerd Hoffmann, Stefan Hajnoczi,
	dirty.ice.hu, Alex Bennée

On 4/29/21 11:59 AM, Markus Armbruster wrote:
> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> is old enough to permit removal.  This is *not* a demand to remove, it's
> a polite request to consider whether the time for removal has come.
> Extra points for telling us in a reply.  "We should remove, but I can't
> do it myself right now" is a valid answer.  Let's review the file:

>     Raspberry Pi ``raspi2`` and ``raspi3`` machines (since 5.2)
>     '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     The Raspberry Pi machines come in various models (A, A+, B, B+). To be able
>     to distinguish which model QEMU is implementing, the ``raspi2`` and ``raspi3``
>     machines have been renamed ``raspi2b`` and ``raspi3b``.

Done:
https://lists.gnu.org/archive/html/qemu-devel/2021-05/msg00492.html

>     nanoMIPS ISA
>     ''''''''''''
> 
>     The ``nanoMIPS`` ISA has never been upstreamed to any compiler toolchain.
>     As it is hard to generate binaries for it, declare it deprecated.

MediaTek said they want to contribute and are in the process of
upstreaming nanoMIPS toolchains, so we'll keep it in this state
until the next release.

Thanks for the reminders,

Phil.


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29 12:40   ` Gerd Hoffmann
  2021-04-29 13:12     ` Kevin Wolf
@ 2021-05-03 15:10     ` Paolo Bonzini
  1 sibling, 0 replies; 33+ messages in thread
From: Paolo Bonzini @ 2021-05-03 15:10 UTC (permalink / raw)
  To: Gerd Hoffmann
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Alex Bennée, Markus Armbruster, qemu-devel,
	Alistair Francis, Stefan Hajnoczi, dirty.ice.hu, Robert Hoo,
	Philippe Mathieu-Daudé

On 29/04/21 14:40, Gerd Hoffmann wrote:
>> In other words you would do something like -audiohw
>> <audiodev-args>,model=xxx and it gets desugared automatically to either
>>
>>     -audiodev <audiodev-args>,id=foo -device devname,audiodev=xxx
>>
>> or
>>
>>     -audiodev <audiodev-args>,id=foo -M propname=foo
> Suggestions how to do that in a clean way?
> Given that -audiodev is qapi-based I tried it this way:

Since this is sugar, I think it's okay to make it desugar into QAPI, 
instead of being QAPI all the way down:

- use qobject_input_visitor_new_str in softmmu/vl.c

- visit the "model" key

- look up the "model", fail if it doesn't match a known model

- pass the rest into a variant of audio_parse_option that takes a 
Visitor and returns and Audiodev*

- pass the id into a constructor function keyed by the model

Paolo



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-05-03  7:12     ` Alistair Francis
@ 2021-05-03 15:13       ` Paolo Bonzini
  2021-05-03 22:57         ` Alistair Francis
  0 siblings, 1 reply; 33+ messages in thread
From: Paolo Bonzini @ 2021-05-03 15:13 UTC (permalink / raw)
  To: Alistair Francis, Thomas Huth
  Cc: Kevin Wolf, Daniel P. Berrangé,
	Markus Armbruster, qemu-devel@nongnu.org Developers, Robert Hoo,
	Alex Bennée, Alistair Francis, Gerd Hoffmann,
	Stefan Hajnoczi, dirty.ice.hu, Philippe Mathieu-Daudé

On 03/05/21 09:12, Alistair Francis wrote:
>> deprecated.rst is mainly thought for the things that only have been marked
>> as deprecated, but not changed yet. Once it's done, the items normally get
>> moved to docs/system/removed-features.rst instead.
> Too easy, I'll move it there instead.

Can you move the description to docs/system/target-riscv.rst?  The 
switch from ``bios none`` to ``-bios default`` in 5.1 can be placed in a 
footnote if desirable, but the documentation of ``-bios`` is worth 
keeping in a more prominent place.

Paolo



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
                   ` (9 preceding siblings ...)
  2021-05-03 13:14 ` Philippe Mathieu-Daudé
@ 2021-05-03 18:21 ` Eric Blake
  2021-05-04 13:59   ` Peter Krempa
  10 siblings, 1 reply; 33+ messages in thread
From: Eric Blake @ 2021-05-03 18:21 UTC (permalink / raw)
  To: Markus Armbruster, qemu-devel; +Cc: Kevin Wolf, Peter Krempa, libvirt-list

On 4/29/21 4:59 AM, Markus Armbruster wrote:
> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> is old enough to permit removal.  This is *not* a demand to remove, it's
> a polite request to consider whether the time for removal has come.
> Extra points for telling us in a reply.  "We should remove, but I can't
> do it myself right now" is a valid answer.  Let's review the file:
> 

[adjusting cc for this response]

> 
> Eric Blake:
> 
>     qemu-img amend to adjust backing file (since 5.1)
>     '''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     The use of ``qemu-img amend`` to modify the name or format of a qcow2
>     backing image is deprecated; this functionality was never fully
>     documented or tested, and interferes with other amend operations that
>     need access to the original backing image (such as deciding whether a
>     v3 zero cluster may be left unallocated when converting to a v2
>     image).  Rather, any changes to the backing chain should be performed
>     with ``qemu-img rebase -u`` either before or after the remaining
>     changes being performed by amend, as appropriate.
> 
>     qemu-img backing file without format (since 5.1)
>     ''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     The use of ``qemu-img create``, ``qemu-img rebase``, or ``qemu-img
>     convert`` to create or modify an image that depends on a backing file
>     now recommends that an explicit backing format be provided.  This is
>     for safety: if QEMU probes a different format than what you thought,
>     the data presented to the guest will be corrupt; similarly, presenting
>     a raw image to a guest allows a potential security exploit if a future
>     probe sees a non-raw image based on guest writes.
> 
>     To avoid the warning message, or even future refusal to create an
>     unsafe image, you must pass ``-o backing_fmt=`` (or the shorthand
>     ``-F`` during create) to specify the intended backing format.  You may
>     use ``qemu-img rebase -u`` to retroactively add a backing format to an
>     existing image.  However, be aware that there are already potential
>     security risks to blindly using ``qemu-img info`` to probe the format
>     of an untrusted backing image, when deciding what format to add into
>     an existing image.

I'm not sure how widely used these were, but I'm game for writing a
patch to drop them.  I'm fairly certain libvirt is not using them.

> 
> Kevin Wolf:
> 
>     ``nbd-server-add`` and ``nbd-server-remove`` (since 5.2)
>     ''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> 
>     Use the more generic commands ``block-export-add`` and ``block-export-del``
>     instead.  As part of this deprecation, where ``nbd-server-add`` used a
>     single ``bitmap``, the new ``block-export-add`` uses a list of ``bitmaps``.

Peter, is libvirt good for this one to go?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-05-03 15:13       ` Paolo Bonzini
@ 2021-05-03 22:57         ` Alistair Francis
  0 siblings, 0 replies; 33+ messages in thread
From: Alistair Francis @ 2021-05-03 22:57 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Kevin Wolf, Thomas Huth, Daniel P. Berrangé,
	Alex Bennée, qemu-devel@nongnu.org Developers,
	Markus Armbruster, Alistair Francis, Gerd Hoffmann,
	Stefan Hajnoczi, dirty.ice.hu, Robert Hoo,
	Philippe Mathieu-Daudé

On Tue, May 4, 2021 at 1:13 AM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 03/05/21 09:12, Alistair Francis wrote:
> >> deprecated.rst is mainly thought for the things that only have been marked
> >> as deprecated, but not changed yet. Once it's done, the items normally get
> >> moved to docs/system/removed-features.rst instead.
> > Too easy, I'll move it there instead.
>
> Can you move the description to docs/system/target-riscv.rst?  The
> switch from ``bios none`` to ``-bios default`` in 5.1 can be placed in a
> footnote if desirable, but the documentation of ``-bios`` is worth
> keeping in a more prominent place.

Good idea. I have sent a patch that adds a line to
`docs/system/removed-features.rst` and the rest of the information is
in the RISC-V documentation.

https://lists.nongnu.org/archive/html/qemu-devel/2021-05/msg00789.html

Alistair

>
> Paolo
>


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Let's remove some deprecated stuff
  2021-05-03 18:21 ` Eric Blake
@ 2021-05-04 13:59   ` Peter Krempa
  0 siblings, 0 replies; 33+ messages in thread
From: Peter Krempa @ 2021-05-04 13:59 UTC (permalink / raw)
  To: Eric Blake; +Cc: Kevin Wolf, libvirt-list, Markus Armbruster, qemu-devel

On Mon, May 03, 2021 at 13:21:47 -0500, Eric Blake wrote:
> On 4/29/21 4:59 AM, Markus Armbruster wrote:

[...]

> >     qemu-img backing file without format (since 5.1)
> >     ''''''''''''''''''''''''''''''''''''''''''''''''
> > 
> >     The use of ``qemu-img create``, ``qemu-img rebase``, or ``qemu-img
> >     convert`` to create or modify an image that depends on a backing file
> >     now recommends that an explicit backing format be provided.  This is
> >     for safety: if QEMU probes a different format than what you thought,
> >     the data presented to the guest will be corrupt; similarly, presenting
> >     a raw image to a guest allows a potential security exploit if a future
> >     probe sees a non-raw image based on guest writes.
> > 
> >     To avoid the warning message, or even future refusal to create an
> >     unsafe image, you must pass ``-o backing_fmt=`` (or the shorthand
> >     ``-F`` during create) to specify the intended backing format.  You may
> >     use ``qemu-img rebase -u`` to retroactively add a backing format to an
> >     existing image.  However, be aware that there are already potential
> >     security risks to blindly using ``qemu-img info`` to probe the format
> >     of an untrusted backing image, when deciding what format to add into
> >     an existing image.
> 
> I'm not sure how widely used these were, but I'm game for writing a
> patch to drop them.  I'm fairly certain libvirt is not using them.

This is certainly seeing some upstream "use" from random scripts and
possibly also libguestfs.

There are few limited scenarios when probing format is still safe if you
are not 100% sure what the original format of the image was.

I'm afraid that removing this will (at least when used with libvirt)
remove the potential detection of the unsafe scenarios and prompt people
to modify their code to do plainly:

1) probe format of backing file
2) use it in the new overlay without considering the implications

This is IMO less-safe because libvirt will consider the backing chain
without questioning security.

> > Kevin Wolf:
> > 
> >     ``nbd-server-add`` and ``nbd-server-remove`` (since 5.2)
> >     ''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> > 
> >     Use the more generic commands ``block-export-add`` and ``block-export-del``
> >     instead.  As part of this deprecation, where ``nbd-server-add`` used a
> >     single ``bitmap``, the new ``block-export-add`` uses a list of ``bitmaps``.
> 
> Peter, is libvirt good for this one to go?

Yes, libvirt added support for block-export-add usage in favor of
nbd-server-add in:

https://gitlab.com/libvirt/libvirt/-/commit/8c67e389d6367af2ef6dbe2f578c585e2150558d
6.8.0-379-g8c67e389d6


It was briefly disabled since qemu decided to change the design of
block-export-add-before it was really released since the change happened
around a libvirt release:

https://gitlab.com/libvirt/libvirt/-/commit/b87cfc957f57c1d9f7e5bf828ee4b23972085991
v6.9.0-rc1-7-gb87cfc957f

and then re-enabled in

https://gitlab.com/libvirt/libvirt/-/commit/42558a43f87f5a3e73bacb88baf425648415a06f
v6.9.0-8-g42558a43f8



^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2021-05-04 14:01 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-29  9:59 Let's remove some deprecated stuff Markus Armbruster
2021-04-29 10:18 ` Gerd Hoffmann
2021-04-29 10:24   ` Daniel P. Berrangé
2021-04-29 10:29     ` Peter Maydell
2021-04-29 10:35       ` Daniel P. Berrangé
2021-04-29 10:55         ` Gerd Hoffmann
2021-04-30 10:47           ` Markus Armbruster
2021-04-29 11:07         ` Paolo Bonzini
2021-04-29 10:25 ` Peter Maydell
2021-04-29 10:32 ` Daniel P. Berrangé
2021-04-30  6:47   ` Markus Armbruster
2021-04-29 11:06 ` Paolo Bonzini
2021-04-29 12:40   ` Gerd Hoffmann
2021-04-29 13:12     ` Kevin Wolf
2021-04-29 13:46       ` Gerd Hoffmann
2021-04-29 15:05         ` Philippe Mathieu-Daudé
2021-04-30  7:01           ` Markus Armbruster
2021-04-30  7:01           ` Gerd Hoffmann
2021-05-03 15:10     ` Paolo Bonzini
2021-04-29 11:17 ` Thomas Huth
2021-04-29 11:24   ` Peter Maydell
2021-05-03 10:39     ` Markus Armbruster
2021-04-29 14:49 ` Stefan Hajnoczi
2021-04-29 16:32 ` Eduardo Habkost
2021-04-30  3:22 ` Robert Hoo
2021-05-03  1:41 ` Alistair Francis
2021-05-03  4:49   ` Thomas Huth
2021-05-03  7:12     ` Alistair Francis
2021-05-03 15:13       ` Paolo Bonzini
2021-05-03 22:57         ` Alistair Francis
2021-05-03 13:14 ` Philippe Mathieu-Daudé
2021-05-03 18:21 ` Eric Blake
2021-05-04 13:59   ` Peter Krempa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).