* [Qemu-devel] [PATCH] Deprecate the -enable-hax option
@ 2018-06-25 18:22 Thomas Huth
2018-06-25 18:28 ` Paolo Bonzini
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Huth @ 2018-06-25 18:22 UTC (permalink / raw)
To: qemu-devel, Paolo Bonzini; +Cc: Markus Armbruster
We currently have got three ways of turning on the HAX accelerator:
"-machine accel=hax", "-accel hax" and "-enable-hax". That's really
confusing and overloaded. Since "-accel" is our preferred way to enable
an accelerator nowadays, and "-accel hax" is even less to type than
"-enable-hax", let's deprecate the "-enable-hax" option now.
Note: While "-enable-kvm" is available since a long time and can hardly be
removed since it is used in a lot of upper layer tools and scripts, the
"-enable-hax" option is still rather new and not very widespread yet, so
I think that it should be OK if we remove this in a couple of releases again
(we'll see whether someone complains after seeing the deprecation message -
then we could still reconsider to keep it if there a well-founded reasons).
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
Let's give this a try at least :-)
qemu-doc.texi | 4 ++++
qemu-options.hx | 2 +-
vl.c | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/qemu-doc.texi b/qemu-doc.texi
index 16fcb47..ac5ca34 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -2912,6 +2912,10 @@ Option @option{-virtioconsole} has been replaced by
The @code{-clock} option is ignored since QEMU version 1.7.0. There is no
replacement since it is not needed anymore.
+@subsection -enable-hax (since 3.0.0)
+
+The @option{-enable-hax} option has been replaced by @option{-accel hax}.
+
@section QEMU Machine Protocol (QMP) commands
@subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0)
diff --git a/qemu-options.hx b/qemu-options.hx
index d5b0c26..d811072 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3421,7 +3421,7 @@ STEXI
Enable HAX (Hardware-based Acceleration eXecution) support. This option
is only available if HAX support is enabled when compiling. HAX is only
applicable to MAC and Windows platform, and thus does not conflict with
-KVM.
+KVM. This option is deprecated, use @option{-accel hax} instead.
ETEXI
DEF("xen-domid", HAS_ARG, QEMU_OPTION_xen_domid,
diff --git a/vl.c b/vl.c
index 5d8a9df..c13d589 100644
--- a/vl.c
+++ b/vl.c
@@ -3581,6 +3581,7 @@ int main(int argc, char **argv, char **envp)
qemu_opts_parse_noisily(olist, "accel=kvm", false);
break;
case QEMU_OPTION_enable_hax:
+ warn_report("Option is deprecated, use '-accel hax' instead");
olist = qemu_find_opts("machine");
qemu_opts_parse_noisily(olist, "accel=hax", false);
break;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] [PATCH] Deprecate the -enable-hax option
2018-06-25 18:22 [Qemu-devel] [PATCH] Deprecate the -enable-hax option Thomas Huth
@ 2018-06-25 18:28 ` Paolo Bonzini
2018-06-25 18:50 ` Stefan Weil
0 siblings, 1 reply; 3+ messages in thread
From: Paolo Bonzini @ 2018-06-25 18:28 UTC (permalink / raw)
To: Thomas Huth, qemu-devel; +Cc: Markus Armbruster
On 25/06/2018 20:22, Thomas Huth wrote:
> We currently have got three ways of turning on the HAX accelerator:
> "-machine accel=hax", "-accel hax" and "-enable-hax". That's really
> confusing and overloaded. Since "-accel" is our preferred way to enable
> an accelerator nowadays, and "-accel hax" is even less to type than
> "-enable-hax", let's deprecate the "-enable-hax" option now.
>
> Note: While "-enable-kvm" is available since a long time and can hardly be
> removed since it is used in a lot of upper layer tools and scripts, the
> "-enable-hax" option is still rather new and not very widespread yet, so
> I think that it should be OK if we remove this in a couple of releases again
> (we'll see whether someone complains after seeing the deprecation message -
> then we could still reconsider to keep it if there a well-founded reasons).
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
> Let's give this a try at least :-)
Sounds good, queued.
Paolo
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] [PATCH] Deprecate the -enable-hax option
2018-06-25 18:28 ` Paolo Bonzini
@ 2018-06-25 18:50 ` Stefan Weil
0 siblings, 0 replies; 3+ messages in thread
From: Stefan Weil @ 2018-06-25 18:50 UTC (permalink / raw)
To: Paolo Bonzini, Thomas Huth, qemu-devel; +Cc: Markus Armbruster
Am 25.06.2018 um 20:28 schrieb Paolo Bonzini:
> On 25/06/2018 20:22, Thomas Huth wrote:
>> We currently have got three ways of turning on the HAX accelerator:
>> "-machine accel=hax", "-accel hax" and "-enable-hax". That's really
>> confusing and overloaded. Since "-accel" is our preferred way to enable
>> an accelerator nowadays, and "-accel hax" is even less to type than
>> "-enable-hax", let's deprecate the "-enable-hax" option now.
>>
>> Note: While "-enable-kvm" is available since a long time and can hardly be
>> removed since it is used in a lot of upper layer tools and scripts, the
>> "-enable-hax" option is still rather new and not very widespread yet, so
>> I think that it should be OK if we remove this in a couple of releases again
>> (we'll see whether someone complains after seeing the deprecation message -
>> then we could still reconsider to keep it if there a well-founded reasons).
>>
>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> ---
>> Let's give this a try at least :-)
>
> Sounds good, queued.
>
> Paolo
>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
I would not mind if --enable-hax were removed soon, as I don't think it
was widely used.
Stefan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-06-25 18:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-25 18:22 [Qemu-devel] [PATCH] Deprecate the -enable-hax option Thomas Huth
2018-06-25 18:28 ` Paolo Bonzini
2018-06-25 18:50 ` Stefan Weil
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).