Re: [PATCH for-7.0] i386: Deprecate the -no-hpet QEMU command line option

On 06/12/2021 09.40, Thomas Huth wrote:
The HPET setting has been turned into a machine property a while ago already, so we should finally do the next step and deprecate the legacy CLI option, too. While we're at it, add a proper help text for the machine property, too.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 6 ++++++ hw/i386/pc.c | 2 ++ qemu-options.hx | 2 +- softmmu/vl.c | 1 + 4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 5693abb663..1dfe69aa6a 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -198,6 +198,12 @@ form is preferred. Using ``-drive if=none`` to configure the OTP device of the sifive_u RISC-V machine is deprecated. Use ``-drive if=pflash`` instead.
+``-no-hpet`` (since 7.0) +'''''''''''''''''''''''' + +The HPET setting has been turned into a machine property. +Use ``-machine hpet=off`` instead. [...]
Forgot to CC: the libvirt folks, doing so now. Seems like libvirt is still using -no-hpet in some few spots, so I guess these would need to be changed first, before we could finally remove this option in QEMU? Thomas

On Mon, Dec 06, 2021 at 09:47:58 +0100, Thomas Huth wrote:
On 06/12/2021 09.40, Thomas Huth wrote:
The HPET setting has been turned into a machine property a while ago already, so we should finally do the next step and deprecate the legacy CLI option, too. While we're at it, add a proper help text for the machine property, too.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 6 ++++++ hw/i386/pc.c | 2 ++ qemu-options.hx | 2 +- softmmu/vl.c | 1 + 4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 5693abb663..1dfe69aa6a 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -198,6 +198,12 @@ form is preferred. Using ``-drive if=none`` to configure the OTP device of the sifive_u RISC-V machine is deprecated. Use ``-drive if=pflash`` instead. +``-no-hpet`` (since 7.0) +'''''''''''''''''''''''' + +The HPET setting has been turned into a machine property. +Use ``-machine hpet=off`` instead. [...]
Forgot to CC: the libvirt folks, doing so now.
Seems like libvirt is still using -no-hpet in some few spots, so I guess these would need to be changed first, before we could finally remove this option in QEMU?
Yes we need to switch to the new property first. Is the new way via -machine property by any chance usable with qemu-2.11? If yes, then we can do it unconditionally, otherwise we'll need a witness to detect the support for the new flag as a qemu capability.

On 06/12/2021 09.57, Peter Krempa wrote:
On Mon, Dec 06, 2021 at 09:47:58 +0100, Thomas Huth wrote:
On 06/12/2021 09.40, Thomas Huth wrote:
The HPET setting has been turned into a machine property a while ago already, so we should finally do the next step and deprecate the legacy CLI option, too. While we're at it, add a proper help text for the machine property, too.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 6 ++++++ hw/i386/pc.c | 2 ++ qemu-options.hx | 2 +- softmmu/vl.c | 1 + 4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 5693abb663..1dfe69aa6a 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -198,6 +198,12 @@ form is preferred. Using ``-drive if=none`` to configure the OTP device of the sifive_u RISC-V machine is deprecated. Use ``-drive if=pflash`` instead. +``-no-hpet`` (since 7.0) +'''''''''''''''''''''''' + +The HPET setting has been turned into a machine property. +Use ``-machine hpet=off`` instead. [...]
Forgot to CC: the libvirt folks, doing so now.
Seems like libvirt is still using -no-hpet in some few spots, so I guess these would need to be changed first, before we could finally remove this option in QEMU?
Yes we need to switch to the new property first.
Is the new way via -machine property by any chance usable with qemu-2.11? If yes, then we can do it unconditionally, otherwise we'll need a witness to detect the support for the new flag as a qemu capability.
The machine property has been added just a year ago: https://gitlab.com/qemu-project/qemu/-/commit/0259c78ca79 So it's just available on QEMU v5.2.0 and newer. Thomas

On Mon, Dec 06, 2021 at 10:02:44 +0100, Thomas Huth wrote:
On 06/12/2021 09.57, Peter Krempa wrote:
On Mon, Dec 06, 2021 at 09:47:58 +0100, Thomas Huth wrote:
On 06/12/2021 09.40, Thomas Huth wrote:
The HPET setting has been turned into a machine property a while ago already, so we should finally do the next step and deprecate the legacy CLI option, too. While we're at it, add a proper help text for the machine property, too.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 6 ++++++ hw/i386/pc.c | 2 ++ qemu-options.hx | 2 +- softmmu/vl.c | 1 + 4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 5693abb663..1dfe69aa6a 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -198,6 +198,12 @@ form is preferred. Using ``-drive if=none`` to configure the OTP device of the sifive_u RISC-V machine is deprecated. Use ``-drive if=pflash`` instead. +``-no-hpet`` (since 7.0) +'''''''''''''''''''''''' + +The HPET setting has been turned into a machine property. +Use ``-machine hpet=off`` instead. [...]
Forgot to CC: the libvirt folks, doing so now.
Seems like libvirt is still using -no-hpet in some few spots, so I guess these would need to be changed first, before we could finally remove this option in QEMU?
Yes we need to switch to the new property first.
Is the new way via -machine property by any chance usable with qemu-2.11? If yes, then we can do it unconditionally, otherwise we'll need a witness to detect the support for the new flag as a qemu capability.
The machine property has been added just a year ago:
https://gitlab.com/qemu-project/qemu/-/commit/0259c78ca79
So it's just available on QEMU v5.2.0 and newer.
Okay, so we can't unfortunately always use the new way. I had a brief look in what libvirt queries to build the capability list and unfortunately neither query-command-line-options nor query-machines list anything which we could detect. Since only the config knob is changing the presence in qom-list-types doesn't help either. So if qemu want's to deprecate the '-no-hpet' spelling we need something which we can detect by one of the above means or other probe command to use the new spelling.

On 06/12/2021 10.19, Peter Krempa wrote:
On Mon, Dec 06, 2021 at 10:02:44 +0100, Thomas Huth wrote:
On 06/12/2021 09.57, Peter Krempa wrote:
On Mon, Dec 06, 2021 at 09:47:58 +0100, Thomas Huth wrote:
On 06/12/2021 09.40, Thomas Huth wrote:
The HPET setting has been turned into a machine property a while ago already, so we should finally do the next step and deprecate the legacy CLI option, too. While we're at it, add a proper help text for the machine property, too.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 6 ++++++ hw/i386/pc.c | 2 ++ qemu-options.hx | 2 +- softmmu/vl.c | 1 + 4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 5693abb663..1dfe69aa6a 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -198,6 +198,12 @@ form is preferred. Using ``-drive if=none`` to configure the OTP device of the sifive_u RISC-V machine is deprecated. Use ``-drive if=pflash`` instead. +``-no-hpet`` (since 7.0) +'''''''''''''''''''''''' + +The HPET setting has been turned into a machine property. +Use ``-machine hpet=off`` instead. [...]
Forgot to CC: the libvirt folks, doing so now.
Seems like libvirt is still using -no-hpet in some few spots, so I guess these would need to be changed first, before we could finally remove this option in QEMU?
Yes we need to switch to the new property first.
Is the new way via -machine property by any chance usable with qemu-2.11? If yes, then we can do it unconditionally, otherwise we'll need a witness to detect the support for the new flag as a qemu capability.
The machine property has been added just a year ago:
https://gitlab.com/qemu-project/qemu/-/commit/0259c78ca79
So it's just available on QEMU v5.2.0 and newer.
Okay, so we can't unfortunately always use the new way.
I had a brief look in what libvirt queries to build the capability list and unfortunately neither query-command-line-options nor query-machines list anything which we could detect.
Since only the config knob is changing the presence in qom-list-types doesn't help either.
So if qemu want's to deprecate the '-no-hpet' spelling we need something which we can detect by one of the above means or other probe command to use the new spelling.
I just had another chat with Peter on IRC, and seems like it could be detected by running "qom-list-properties" on e.g. the "generic-pc-machine" object. However, libvirt does not have that information in their test data yet, so it's not a very trivial change to support this in libvirt. Thus, please don't merge this patch yet, it will currently cause more hassle than benefit. Thomas

On Mon, Dec 06, 2021 at 10:44:50AM +0100, Thomas Huth wrote:
On 06/12/2021 10.19, Peter Krempa wrote:
On Mon, Dec 06, 2021 at 10:02:44 +0100, Thomas Huth wrote:
On 06/12/2021 09.57, Peter Krempa wrote:
On Mon, Dec 06, 2021 at 09:47:58 +0100, Thomas Huth wrote:
On 06/12/2021 09.40, Thomas Huth wrote:
The HPET setting has been turned into a machine property a while ago already, so we should finally do the next step and deprecate the legacy CLI option, too. While we're at it, add a proper help text for the machine property, too.
Signed-off-by: Thomas Huth <thuth@redhat.com> --- docs/about/deprecated.rst | 6 ++++++ hw/i386/pc.c | 2 ++ qemu-options.hx | 2 +- softmmu/vl.c | 1 + 4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 5693abb663..1dfe69aa6a 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -198,6 +198,12 @@ form is preferred. Using ``-drive if=none`` to configure the OTP device of the sifive_u RISC-V machine is deprecated. Use ``-drive if=pflash`` instead. +``-no-hpet`` (since 7.0) +'''''''''''''''''''''''' + +The HPET setting has been turned into a machine property. +Use ``-machine hpet=off`` instead. [...]
Forgot to CC: the libvirt folks, doing so now.
Seems like libvirt is still using -no-hpet in some few spots, so I guess these would need to be changed first, before we could finally remove this option in QEMU?
Yes we need to switch to the new property first.
Is the new way via -machine property by any chance usable with qemu-2.11? If yes, then we can do it unconditionally, otherwise we'll need a witness to detect the support for the new flag as a qemu capability.
The machine property has been added just a year ago:
https://gitlab.com/qemu-project/qemu/-/commit/0259c78ca79
So it's just available on QEMU v5.2.0 and newer.
Okay, so we can't unfortunately always use the new way.
I had a brief look in what libvirt queries to build the capability list and unfortunately neither query-command-line-options nor query-machines list anything which we could detect.
Since only the config knob is changing the presence in qom-list-types doesn't help either.
So if qemu want's to deprecate the '-no-hpet' spelling we need something which we can detect by one of the above means or other probe command to use the new spelling.
I just had another chat with Peter on IRC, and seems like it could be detected by running "qom-list-properties" on e.g. the "generic-pc-machine" object. However, libvirt does not have that information in their test data yet, so it's not a very trivial change to support this in libvirt.
It is mostly just a tedious matter of getting sample QMP replies for the qom-list-properties command on various older QEMU versions to make sure our test suite does the right thing.
Thus, please don't merge this patch yet, it will currently cause more hassle than benefit.
I don't see any problem in QEMU going ahead with this. If it is deprecated in 7.0, then it won't be until 7.2 that its deleted, which is Dec 2022 timeframe. A year is enough time for libvirt to adapt. 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 :|
participants (3)
-
Daniel P. Berrangé
-
Peter Krempa
-
Thomas Huth