We've got three ways of enabling an accelerator: -machine accel=xyz,
-accel xyz and -enable-xyz. For new QEMU users, this must be very
confusing ("Which one do I have to use? Is there a difference between
the options?"). While -enable-kvm was useful in the past, there is no
real good reason for using it anymore today ("-accel kvm" is even less
to type than "-enable-kvm"), so let's decrease the confusing amount of
options in our documenation a little bit by removing the -enable-xyz
here. Note that the option itself is neither removed nor marked as
deprecated - since -enable-kvm is likely used in a lot of scripts and
since its code is easy to maintain, we should keep it around to avoid
to break old setups.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 PS: I guess Paolo won't like this patch ... let's try it anyway ;-)

 qemu-options.hx | 22 ++++------------------
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 0ec9cac..f33a81e 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3414,25 +3414,11 @@ STEXI
 Set the filename for the BIOS.
 ETEXI
 
-DEF("enable-kvm", 0, QEMU_OPTION_enable_kvm, \
-    "-enable-kvm     enable KVM full virtualization support\n", QEMU_ARCH_ALL)
-STEXI
-@item -enable-kvm
-@findex -enable-kvm
-Enable KVM full virtualization support. This option is only available
-if KVM support is enabled when compiling.
-ETEXI
+HXCOMM -accel kvm should be used instead, thus this is not documented anymore
+DEF("enable-kvm", 0, QEMU_OPTION_enable_kvm, "", QEMU_ARCH_ALL)
 
-DEF("enable-hax", 0, QEMU_OPTION_enable_hax, \
-    "-enable-hax     enable HAX virtualization support\n", QEMU_ARCH_I386)
-STEXI
-@item -enable-hax
-@findex -enable-hax
-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.
-ETEXI
+HXCOMM -accel hax should be used instead, thus this is not documented anymore
+DEF("enable-hax", 0, QEMU_OPTION_enable_hax, "", QEMU_ARCH_I386)
 
 DEF("xen-domid", HAS_ARG, QEMU_OPTION_xen_domid,
     "-xen-domid id   specify xen guest domain id\n", QEMU_ARCH_ALL)
-- 
1.8.3.1

On 13/06/2018 07:05, Thomas Huth wrote:
> We've got three ways of enabling an accelerator: -machine accel=xyz,
> -accel xyz and -enable-xyz. For new QEMU users, this must be very
> confusing ("Which one do I have to use? Is there a difference between
> the options?"). While -enable-kvm was useful in the past, there is no
> real good reason for using it anymore today ("-accel kvm" is even less
> to type than "-enable-kvm"), so let's decrease the confusing amount of
> options in our documenation a little bit by removing the -enable-xyz
> here. Note that the option itself is neither removed nor marked as
> deprecated - since -enable-kvm is likely used in a lot of scripts and
> since its code is easy to maintain, we should keep it around to avoid
> to break old setups.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  PS: I guess Paolo won't like this patch ... let's try it anyway ;-)

Heh.  I'm not sure actually.  I'm more in favor of introducing an
"Obsolete options" section and putting it there.

Paolo


>  qemu-options.hx | 22 ++++------------------
>  1 file changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 0ec9cac..f33a81e 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -3414,25 +3414,11 @@ STEXI
>  Set the filename for the BIOS.
>  ETEXI
>  
> -DEF("enable-kvm", 0, QEMU_OPTION_enable_kvm, \
> -    "-enable-kvm     enable KVM full virtualization support\n", QEMU_ARCH_ALL)
> -STEXI
> -@item -enable-kvm
> -@findex -enable-kvm
> -Enable KVM full virtualization support. This option is only available
> -if KVM support is enabled when compiling.
> -ETEXI
> +HXCOMM -accel kvm should be used instead, thus this is not documented anymore
> +DEF("enable-kvm", 0, QEMU_OPTION_enable_kvm, "", QEMU_ARCH_ALL)
>  
> -DEF("enable-hax", 0, QEMU_OPTION_enable_hax, \
> -    "-enable-hax     enable HAX virtualization support\n", QEMU_ARCH_I386)
> -STEXI
> -@item -enable-hax
> -@findex -enable-hax
> -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.
> -ETEXI
> +HXCOMM -accel hax should be used instead, thus this is not documented anymore
> +DEF("enable-hax", 0, QEMU_OPTION_enable_hax, "", QEMU_ARCH_I386)
>  
>  DEF("xen-domid", HAS_ARG, QEMU_OPTION_xen_domid,
>      "-xen-domid id   specify xen guest domain id\n", QEMU_ARCH_ALL)
> 

On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
> We've got three ways of enabling an accelerator: -machine accel=xyz,
> -accel xyz and -enable-xyz. For new QEMU users, this must be very
> confusing ("Which one do I have to use? Is there a difference between
> the options?"). While -enable-kvm was useful in the past, there is no
> real good reason for using it anymore today ("-accel kvm" is even less
> to type than "-enable-kvm"), so let's decrease the confusing amount of
> options in our documenation a little bit by removing the -enable-xyz
> here. Note that the option itself is neither removed nor marked as
> deprecated - since -enable-kvm is likely used in a lot of scripts and
> since its code is easy to maintain, we should keep it around to avoid
> to break old setups.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  PS: I guess Paolo won't like this patch ... let's try it anyway ;-)

It's widely used and we're removing the documentation for it?!  That is
likely to cause issues for new users who refer to the man page to
understand the QEMU command-lines they see online, in scripts, etc.

IMO -enable-kvm is not worth inconveniencing users about.  We gain very
little from abolishing it from docs and/or code, but its absence will
annoy our users.

On Wed, Jun 13, 2018 at 02:38:40PM +0100, Stefan Hajnoczi wrote:
> On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
> > We've got three ways of enabling an accelerator: -machine accel=xyz,
> > -accel xyz and -enable-xyz. For new QEMU users, this must be very
> > confusing ("Which one do I have to use? Is there a difference between
> > the options?"). While -enable-kvm was useful in the past, there is no
> > real good reason for using it anymore today ("-accel kvm" is even less
> > to type than "-enable-kvm"), so let's decrease the confusing amount of
> > options in our documenation a little bit by removing the -enable-xyz
> > here. Note that the option itself is neither removed nor marked as
> > deprecated - since -enable-kvm is likely used in a lot of scripts and
> > since its code is easy to maintain, we should keep it around to avoid
> > to break old setups.
> > 
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > ---
> >  PS: I guess Paolo won't like this patch ... let's try it anyway ;-)
> 
> It's widely used and we're removing the documentation for it?!  That is
> likely to cause issues for new users who refer to the man page to
> understand the QEMU command-lines they see online, in scripts, etc.

Agreed, this is a very bad idea. Any option that is accepted by QEMU,
but not documented is a bug that must be fixed. IOW removing docs
is creating bugs.

If we want to help users understand why we have -enable-kvm, just
make the docs say that it is syntactic for '-machine accel=kvm'.
Users can decide for themselves whether they want to switch to
the more verbose way or not

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 :|

On 13.06.2018 15:44, Daniel P. Berrangé wrote:
> On Wed, Jun 13, 2018 at 02:38:40PM +0100, Stefan Hajnoczi wrote:
>> On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
>>> We've got three ways of enabling an accelerator: -machine accel=xyz,
>>> -accel xyz and -enable-xyz. For new QEMU users, this must be very
>>> confusing ("Which one do I have to use? Is there a difference between
>>> the options?"). While -enable-kvm was useful in the past, there is no
>>> real good reason for using it anymore today ("-accel kvm" is even less
>>> to type than "-enable-kvm"), so let's decrease the confusing amount of
>>> options in our documenation a little bit by removing the -enable-xyz
>>> here. Note that the option itself is neither removed nor marked as
>>> deprecated - since -enable-kvm is likely used in a lot of scripts and
>>> since its code is easy to maintain, we should keep it around to avoid
>>> to break old setups.
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>> ---
>>>  PS: I guess Paolo won't like this patch ... let's try it anyway ;-)
>>
>> It's widely used and we're removing the documentation for it?!  That is
>> likely to cause issues for new users who refer to the man page to
>> understand the QEMU command-lines they see online, in scripts, etc.
> 
> Agreed, this is a very bad idea. Any option that is accepted by QEMU,
> but not documented is a bug that must be fixed. IOW removing docs
> is creating bugs.

Not documenting unliked options that are still kept for compatibility
was at least a common practice in the past (see -no-kvm for example, or
many of those deprecated options like -net channel that have been
removed in the past year).

> If we want to help users understand why we have -enable-kvm, just
> make the docs say that it is syntactic for '-machine accel=kvm'.
> Users can decide for themselves whether they want to switch to
> the more verbose way or not

Uh, well, in this case "-enable-kvm" is already the more verbose way:
"-accel kvm" is shorter :-)

It's just a big mess: We've got -enable-kvm, -enable-hax, but there is
no -enable-hvf, -enable-whpx or -enable-xen option. And to force TCG
mode, you've got to use -no-kvm ... honestly, if I were a new user, I'd
simply say: WTF!?!

But ok, since -enable-kvm has such a big tradition and is used in a lot
of examples out there, it's likely really better if we keep it in the
documentation. But we should either move it to a "obsolete option"
chapter, or update the current documentation with some words like
"obsolete" or "legacy" (to make it clear that nobody gets the idea of
introducing -enable-hvf or other similar options in the future).

And what about -enable-hax? That hardly has any tradtion. Should we
maybe even deprecate it?

 Thomas

On Wed, Jun 13, 2018 at 05:11:51PM +0200, Thomas Huth wrote:
> On 13.06.2018 15:44, Daniel P. Berrangé wrote:
> > On Wed, Jun 13, 2018 at 02:38:40PM +0100, Stefan Hajnoczi wrote:
> >> On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
> >>> We've got three ways of enabling an accelerator: -machine accel=xyz,
> >>> -accel xyz and -enable-xyz. For new QEMU users, this must be very
> >>> confusing ("Which one do I have to use? Is there a difference between
> >>> the options?"). While -enable-kvm was useful in the past, there is no
> >>> real good reason for using it anymore today ("-accel kvm" is even less
> >>> to type than "-enable-kvm"), so let's decrease the confusing amount of
> >>> options in our documenation a little bit by removing the -enable-xyz
> >>> here. Note that the option itself is neither removed nor marked as
> >>> deprecated - since -enable-kvm is likely used in a lot of scripts and
> >>> since its code is easy to maintain, we should keep it around to avoid
> >>> to break old setups.
> >>>
> >>> Signed-off-by: Thomas Huth <thuth@redhat.com>
> >>> ---
> >>>  PS: I guess Paolo won't like this patch ... let's try it anyway ;-)
> >>
> >> It's widely used and we're removing the documentation for it?!  That is
> >> likely to cause issues for new users who refer to the man page to
> >> understand the QEMU command-lines they see online, in scripts, etc.
> > 
> > Agreed, this is a very bad idea. Any option that is accepted by QEMU,
> > but not documented is a bug that must be fixed. IOW removing docs
> > is creating bugs.
> 
> Not documenting unliked options that are still kept for compatibility
> was at least a common practice in the past (see -no-kvm for example, or
> many of those deprecated options like -net channel that have been
> removed in the past year).

If we're planning to deprecate & then delete an option, then I
don't mind if docs are dropped, but IIUC, in this case we're
not doing that - the option will essentially exist forever.

> > If we want to help users understand why we have -enable-kvm, just
> > make the docs say that it is syntactic for '-machine accel=kvm'.
> > Users can decide for themselves whether they want to switch to
> > the more verbose way or not
> 
> Uh, well, in this case "-enable-kvm" is already the more verbose way:
> "-accel kvm" is shorter :-)

If I'm a user looking for how to enable KVM, then -enable-kvm is the
one I'll pick because of the obvious name.

> It's just a big mess: We've got -enable-kvm, -enable-hax, but there is
> no -enable-hvf, -enable-whpx or -enable-xen option. And to force TCG
> mode, you've got to use -no-kvm ... honestly, if I were a new user, I'd
> simply say: WTF!?!

Personally I'd just clean that up by just adding the missing
-enable-xxx options for consistency :-)

> But ok, since -enable-kvm has such a big tradition and is used in a lot
> of examples out there, it's likely really better if we keep it in the
> documentation. But we should either move it to a "obsolete option"
> chapter, or update the current documentation with some words like
> "obsolete" or "legacy" (to make it clear that nobody gets the idea of
> introducing -enable-hvf or other similar options in the future).
> 
> And what about -enable-hax? That hardly has any tradtion. Should we
> maybe even deprecate it?

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 :|

On 13.06.2018 17:19, Daniel P. Berrangé wrote:
> On Wed, Jun 13, 2018 at 05:11:51PM +0200, Thomas Huth wrote:
>> On 13.06.2018 15:44, Daniel P. Berrangé wrote:
>>> On Wed, Jun 13, 2018 at 02:38:40PM +0100, Stefan Hajnoczi wrote:
>>>> On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
>>>>> We've got three ways of enabling an accelerator: -machine accel=xyz,
>>>>> -accel xyz and -enable-xyz. For new QEMU users, this must be very
>>>>> confusing ("Which one do I have to use? Is there a difference between
>>>>> the options?"). While -enable-kvm was useful in the past, there is no
>>>>> real good reason for using it anymore today ("-accel kvm" is even less
>>>>> to type than "-enable-kvm"), so let's decrease the confusing amount of
>>>>> options in our documenation a little bit by removing the -enable-xyz
>>>>> here. Note that the option itself is neither removed nor marked as
>>>>> deprecated - since -enable-kvm is likely used in a lot of scripts and
>>>>> since its code is easy to maintain, we should keep it around to avoid
>>>>> to break old setups.
>>>>>
>>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>>> ---
>>>>>  PS: I guess Paolo won't like this patch ... let's try it anyway ;-)
>>>>
>>>> It's widely used and we're removing the documentation for it?!  That is
>>>> likely to cause issues for new users who refer to the man page to
>>>> understand the QEMU command-lines they see online, in scripts, etc.
>>>
>>> Agreed, this is a very bad idea. Any option that is accepted by QEMU,
>>> but not documented is a bug that must be fixed. IOW removing docs
>>> is creating bugs.
>>
>> Not documenting unliked options that are still kept for compatibility
>> was at least a common practice in the past (see -no-kvm for example, or
>> many of those deprecated options like -net channel that have been
>> removed in the past year).
> 
> If we're planning to deprecate & then delete an option, then I
> don't mind if docs are dropped, but IIUC, in this case we're
> not doing that - the option will essentially exist forever.
> 
>>> If we want to help users understand why we have -enable-kvm, just
>>> make the docs say that it is syntactic for '-machine accel=kvm'.
>>> Users can decide for themselves whether they want to switch to
>>> the more verbose way or not
>>
>> Uh, well, in this case "-enable-kvm" is already the more verbose way:
>> "-accel kvm" is shorter :-)
> 
> If I'm a user looking for how to enable KVM, then -enable-kvm is the
> one I'll pick because of the obvious name.

Hmm, maybe we should also add -configure-network-backend,
--configure-character-device-backend and -setup-block-backend as
synonyms for -netdev, -chardev and -blockdev, just because they have a
more obvious name? ;-)

 Thomas

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

> On Wed, Jun 13, 2018 at 05:11:51PM +0200, Thomas Huth wrote:
>> On 13.06.2018 15:44, Daniel P. Berrangé wrote:
>> > On Wed, Jun 13, 2018 at 02:38:40PM +0100, Stefan Hajnoczi wrote:
>> >> On Wed, Jun 13, 2018 at 07:05:21AM +0200, Thomas Huth wrote:
>> >>> We've got three ways of enabling an accelerator: -machine accel=xyz,
>> >>> -accel xyz and -enable-xyz. For new QEMU users, this must be very
>> >>> confusing ("Which one do I have to use? Is there a difference between
>> >>> the options?"). While -enable-kvm was useful in the past, there is no
>> >>> real good reason for using it anymore today ("-accel kvm" is even less
>> >>> to type than "-enable-kvm"), so let's decrease the confusing amount of
>> >>> options in our documenation a little bit by removing the -enable-xyz
>> >>> here. Note that the option itself is neither removed nor marked as
>> >>> deprecated - since -enable-kvm is likely used in a lot of scripts and
>> >>> since its code is easy to maintain, we should keep it around to avoid
>> >>> to break old setups.
>> >>>
>> >>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> >>> ---
>> >>>  PS: I guess Paolo won't like this patch ... let's try it anyway ;-)
>> >>
>> >> It's widely used and we're removing the documentation for it?!  That is
>> >> likely to cause issues for new users who refer to the man page to
>> >> understand the QEMU command-lines they see online, in scripts, etc.
>> > 
>> > Agreed, this is a very bad idea. Any option that is accepted by QEMU,
>> > but not documented is a bug that must be fixed. IOW removing docs
>> > is creating bugs.
>> 
>> Not documenting unliked options that are still kept for compatibility
>> was at least a common practice in the past (see -no-kvm for example, or
>> many of those deprecated options like -net channel that have been
>> removed in the past year).

Not least because both --help output and the user manual are hard enough
to read without them droning about umpteen deprecated things you could
also use, but shouldn't.

> If we're planning to deprecate & then delete an option, then I
> don't mind if docs are dropped,

De-documenting deprecated options that warn "use this instead" feels
like a no-brainer to me.

>                                 but IIUC, in this case we're
> not doing that - the option will essentially exist forever.

Deprecated option: something we don't want users to use, and intend to
remove.  It should warn on use, pointing to the replacement, and
documentation should no longer cover it.

Convenience option: something we consider perfectly fine to use, say
because it's much less typing.  Document normally.

Legacy option: something in between, i.e. we don't intend to remove it,
but we don't want to advertise it, either.  The less of those we have,
the happier I am.  Their documentation to be shunted out of the way, so
users can find it if they need it, but won't find it *first* when they
look for how to do something.

>> > If we want to help users understand why we have -enable-kvm, just
>> > make the docs say that it is syntactic for '-machine accel=kvm'.
>> > Users can decide for themselves whether they want to switch to
>> > the more verbose way or not
>> 
>> Uh, well, in this case "-enable-kvm" is already the more verbose way:
>> "-accel kvm" is shorter :-)
>
> If I'm a user looking for how to enable KVM, then -enable-kvm is the
> one I'll pick because of the obvious name.

Why does a user have to know how to enable KVM?  Oh, because our default
is "run this guest much slower than necessary".  Great!

By "pick", I guess you mean "pick out of output of --help".  If the only
occurence of KVM there was --accel kvm, I trust the user would pick that
without any trouble.  Less confusing than what we have now, I'd say.

>> It's just a big mess: We've got -enable-kvm, -enable-hax, but there is
>> no -enable-hvf, -enable-whpx or -enable-xen option. And to force TCG
>> mode, you've got to use -no-kvm ... honestly, if I were a new user, I'd
>> simply say: WTF!?!
>
> Personally I'd just clean that up by just adding the missing
> -enable-xxx options for consistency :-)

I disagree.  The way to a saner QEMU CLI is reducing crap, not adding
crap for consistency.

>> But ok, since -enable-kvm has such a big tradition and is used in a lot
>> of examples out there, it's likely really better if we keep it in the
>> documentation. But we should either move it to a "obsolete option"
>> chapter, or update the current documentation with some words like
>> "obsolete" or "legacy" (to make it clear that nobody gets the idea of
>> introducing -enable-hvf or other similar options in the future).
>> 
>> And what about -enable-hax? That hardly has any tradtion. Should we
>> maybe even deprecate it?

I would, but it's not a hill I'm prepared to die on.

On Wed, 13 Jun 2018 18:02:27 +0200
Markus Armbruster <armbru@redhat.com> wrote:

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

> > If I'm a user looking for how to enable KVM, then -enable-kvm is the
> > one I'll pick because of the obvious name.  
> 
> Why does a user have to know how to enable KVM?  Oh, because our default
> is "run this guest much slower than necessary".  Great!

Should we try again to default to a better accelerator, if possible? I
don't quite recall why we didn't do so the last time that came up...
was it tests?

On 19/06/2018 17:15, Cornelia Huck wrote:
>> Why does a user have to know how to enable KVM?  Oh, because our default
>> is "run this guest much slower than necessary".  Great!
> Should we try again to default to a better accelerator, if possible? I
> don't quite recall why we didn't do so the last time that came up...
> was it tests?

My plan was to create qemu-{kvm,hax,hvf,whpx} binaries that default to a
better accelerator, and leave qemu-system-* as defaulting to TCG.  This
matches what distributions already do.

Paolo

On Tue, Jun 19, 2018 at 06:16:33PM +0200, Paolo Bonzini wrote:
> On 19/06/2018 17:15, Cornelia Huck wrote:
> >> Why does a user have to know how to enable KVM?  Oh, because our default
> >> is "run this guest much slower than necessary".  Great!
> > Should we try again to default to a better accelerator, if possible? I
> > don't quite recall why we didn't do so the last time that came up...
> > was it tests?
> 
> My plan was to create qemu-{kvm,hax,hvf,whpx} binaries that default to a
> better accelerator, and leave qemu-system-* as defaulting to TCG.  This
> matches what distributions already do.

Why is this better than using KVM by default if it's available?

-- 
Eduardo

On 22.06.2018 20:11, Eduardo Habkost wrote:
> On Tue, Jun 19, 2018 at 06:16:33PM +0200, Paolo Bonzini wrote:
>> On 19/06/2018 17:15, Cornelia Huck wrote:
>>>> Why does a user have to know how to enable KVM?  Oh, because our default
>>>> is "run this guest much slower than necessary".  Great!
>>> Should we try again to default to a better accelerator, if possible? I
>>> don't quite recall why we didn't do so the last time that came up...
>>> was it tests?
>>
>> My plan was to create qemu-{kvm,hax,hvf,whpx} binaries that default to a
>> better accelerator, and leave qemu-system-* as defaulting to TCG.  This
>> matches what distributions already do.
> 
> Why is this better than using KVM by default if it's available?

The answer is (as almost always): Compatibility with migration. Nobody
dares to sacrifice that chicken :-(

 Thomas

On Fri, Jun 22, 2018 at 09:19:56PM +0200, Thomas Huth wrote:
> On 22.06.2018 20:11, Eduardo Habkost wrote:
> > On Tue, Jun 19, 2018 at 06:16:33PM +0200, Paolo Bonzini wrote:
> >> On 19/06/2018 17:15, Cornelia Huck wrote:
> >>>> Why does a user have to know how to enable KVM?  Oh, because our default
> >>>> is "run this guest much slower than necessary".  Great!
> >>> Should we try again to default to a better accelerator, if possible? I
> >>> don't quite recall why we didn't do so the last time that came up...
> >>> was it tests?
> >>
> >> My plan was to create qemu-{kvm,hax,hvf,whpx} binaries that default to a
> >> better accelerator, and leave qemu-system-* as defaulting to TCG.  This
> >> matches what distributions already do.
> > 
> > Why is this better than using KVM by default if it's available?
> 
> The answer is (as almost always): Compatibility with migration. Nobody
> dares to sacrifice that chicken :-(

We can now kill it if we announce the feature as deprecated a
couple of releases in advance.

If we declare that compatibility when the accelerator is omitted
is deprecated in 3.0, in QEMU 3.3 we will be free to choose a
different default accelerator.

-- 
Eduardo

On 22/06/2018 21:35, Eduardo Habkost wrote:
>>> Why is this better than using KVM by default if it's available?
>> The answer is (as almost always): Compatibility with migration. Nobody
>> dares to sacrifice that chicken :-(
> We can now kill it if we announce the feature as deprecated a
> couple of releases in advance.
> 
> If we declare that compatibility when the accelerator is omitted
> is deprecated in 3.0, in QEMU 3.3 we will be free to choose a
> different default accelerator.

We can, we don't necessarily want it.

The status quo is that people using KVM are invoking qemu as qemu-kvm,
people using TCG are invoking qemu as qemu-system-*.  All distros are
shipping a qemu-kvm or more rarely kvm binary, which is invariably a
wrapper script except for RHEL because RHEL doesn't have a qemu-system-*
binary at all.

By the way, changing qemu-system-*'s default to e.g. RHEL's "kvm or tcg"
would not help distros that have "-accel kvm" in their /usr/bin/qemu-kvm
script.

All in all, it seems simpler for me to take the status quo, which is
what non-RHEL distros do, and make it part of upstream.

Paolo

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 22/06/2018 21:35, Eduardo Habkost wrote:
>>>> Why is this better than using KVM by default if it's available?
>>> The answer is (as almost always): Compatibility with migration. Nobody
>>> dares to sacrifice that chicken :-(
>> We can now kill it if we announce the feature as deprecated a
>> couple of releases in advance.
>> 
>> If we declare that compatibility when the accelerator is omitted
>> is deprecated in 3.0, in QEMU 3.3 we will be free to choose a
>> different default accelerator.
>
> We can, we don't necessarily want it.
>
> The status quo is that people using KVM are invoking qemu as qemu-kvm,
> people using TCG are invoking qemu as qemu-system-*.  All distros are
> shipping a qemu-kvm or more rarely kvm binary, which is invariably a
> wrapper script except for RHEL because RHEL doesn't have a qemu-system-*
> binary at all.
>
> By the way, changing qemu-system-*'s default to e.g. RHEL's "kvm or tcg"
> would not help distros that have "-accel kvm" in their /usr/bin/qemu-kvm
> script.

It wouldn't hurt them, either.

Attentive distros could even replace the wrapper script by a link.

> All in all, it seems simpler for me to take the status quo, which is
> what non-RHEL distros do, and make it part of upstream.
>
> Paolo

On 25/06/2018 08:50, Markus Armbruster wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> On 22/06/2018 21:35, Eduardo Habkost wrote:
>>>>> Why is this better than using KVM by default if it's available?
>>>> The answer is (as almost always): Compatibility with migration. Nobody
>>>> dares to sacrifice that chicken :-(
>>> We can now kill it if we announce the feature as deprecated a
>>> couple of releases in advance.
>>>
>>> If we declare that compatibility when the accelerator is omitted
>>> is deprecated in 3.0, in QEMU 3.3 we will be free to choose a
>>> different default accelerator.
>>
>> We can, we don't necessarily want it.
>>
>> The status quo is that people using KVM are invoking qemu as qemu-kvm,
>> people using TCG are invoking qemu as qemu-system-*.  All distros are
>> shipping a qemu-kvm or more rarely kvm binary, which is invariably a
>> wrapper script except for RHEL because RHEL doesn't have a qemu-system-*
>> binary at all.
>>
>> By the way, changing qemu-system-*'s default to e.g. RHEL's "kvm or tcg"
>> would not help distros that have "-accel kvm" in their /usr/bin/qemu-kvm
>> script.
> 
> It wouldn't hurt them, either.

Right; to sum up, it does make things a little less consistent for their
users in two ways:

- qemu-system-<native> behaves differently from qemu-system-<others>.
For example, for ARM the default CPU model might not work for KVM, so
you would have to add a "-cpu xxx" option.

- qemu-system-<native> would still need an accelerator option on OS X or
Windows, where there is not quite parity between TCG and the native
accelerator, in terms of either features or stability.  Because of this
we wouldn't be able to change the default to "whatever virtualizing
accelerators are available followed by TCG".

> Attentive distros could even replace the wrapper script by a link.

If they are okay with replacing the "KVM only" semantics with "KVM or
TCG", which I think is generally worse.

Paolo

>> All in all, it seems simpler for me to take the status quo, which is
>> what non-RHEL distros do, and make it part of upstream.

On Mon, Jun 25, 2018 at 12:28:34PM +0200, Paolo Bonzini wrote:
> On 25/06/2018 08:50, Markus Armbruster wrote:
> > Paolo Bonzini <pbonzini@redhat.com> writes:
> > 
> >> On 22/06/2018 21:35, Eduardo Habkost wrote:
> >>>>> Why is this better than using KVM by default if it's available?
> >>>> The answer is (as almost always): Compatibility with migration. Nobody
> >>>> dares to sacrifice that chicken :-(
> >>> We can now kill it if we announce the feature as deprecated a
> >>> couple of releases in advance.
> >>>
> >>> If we declare that compatibility when the accelerator is omitted
> >>> is deprecated in 3.0, in QEMU 3.3 we will be free to choose a
> >>> different default accelerator.
> >>
> >> We can, we don't necessarily want it.
> >>
> >> The status quo is that people using KVM are invoking qemu as qemu-kvm,
> >> people using TCG are invoking qemu as qemu-system-*.  All distros are
> >> shipping a qemu-kvm or more rarely kvm binary, which is invariably a
> >> wrapper script except for RHEL because RHEL doesn't have a qemu-system-*
> >> binary at all.
> >>
> >> By the way, changing qemu-system-*'s default to e.g. RHEL's "kvm or tcg"
> >> would not help distros that have "-accel kvm" in their /usr/bin/qemu-kvm
> >> script.
> > 
> > It wouldn't hurt them, either.
> 
> Right; to sum up, it does make things a little less consistent for their
> users in two ways:
> 
> - qemu-system-<native> behaves differently from qemu-system-<others>.
> For example, for ARM the default CPU model might not work for KVM, so
> you would have to add a "-cpu xxx" option.
> 
> - qemu-system-<native> would still need an accelerator option on OS X or
> Windows, where there is not quite parity between TCG and the native
> accelerator, in terms of either features or stability.  Because of this
> we wouldn't be able to change the default to "whatever virtualizing
> accelerators are available followed by TCG".
> 
> > Attentive distros could even replace the wrapper script by a link.
> 
> If they are okay with replacing the "KVM only" semantics with "KVM or
> TCG", which I think is generally worse.

If we can't get agreement on what's the right default for each
QEMU binary, I think that's yet another reason to document that
upstream QEMU won't guarantee ABI compatibility if -accel is
omitted.

If downstream distributions want to keep promising ABI
compatibility, it will be up to them.

-- 
Eduardo

On 25/06/2018 19:30, Eduardo Habkost wrote:
>>> Attentive distros could even replace the wrapper script by a link.
>> If they are okay with replacing the "KVM only" semantics with "KVM or
>> TCG", which I think is generally worse.
>
> If we can't get agreement on what's the right default for each
> QEMU binary, I think that's yet another reason to document that
> upstream QEMU won't guarantee ABI compatibility if -accel is
> omitted.

Before that we should ask what the benefit is in changing the default
for qemu-system-*.  Nobody is using it in practice to start QEMU with
KVM enabled...

Paolo

> If downstream distributions want to keep promising ABI
> compatibility, it will be up to them.

On Mon, Jun 25, 2018 at 08:26:28PM +0200, Paolo Bonzini wrote:
> On 25/06/2018 19:30, Eduardo Habkost wrote:
> >>> Attentive distros could even replace the wrapper script by a link.
> >> If they are okay with replacing the "KVM only" semantics with "KVM or
> >> TCG", which I think is generally worse.
> >
> > If we can't get agreement on what's the right default for each
> > QEMU binary, I think that's yet another reason to document that
> > upstream QEMU won't guarantee ABI compatibility if -accel is
> > omitted.
> 
> Before that we should ask what the benefit is in changing the default
> for qemu-system-*.  Nobody is using it in practice to start QEMU with
> KVM enabled...

How can you be sure?  If qemu-system-* is installed with KVM
compiled in, libvirt will probe it using
"-machine none,accel=kvm:tcg" and run the VM using
"-machine $MACHINE,accel=kvm".

In either case, I'm not arguing (yet) for changing the default
upstream.  I'm just arguing for upstream QEMU to not make any
promises about the default.

-- 
Eduardo

On 25/06/2018 21:51, Eduardo Habkost wrote:
>> Before that we should ask what the benefit is in changing the default
>> for qemu-system-*.  Nobody is using it in practice to start QEMU with
>> KVM enabled...
>
> How can you be sure?  If qemu-system-* is installed with KVM
> compiled in, libvirt will probe it using
> "-machine none,accel=kvm:tcg" and run the VM using
> "-machine $MACHINE,accel=kvm".

Right, that needs to be qualified with "without libvirt".

> In either case, I'm not arguing (yet) for changing the default
> upstream.  I'm just arguing for upstream QEMU to not make any
> promises about the default.

It would be a guest ABI breakage for TCG guests, so it would only apply
to new machine types.  I don't think it's worth the complication.

BTW, another thing that needs documenting is ABI promises for HAX and
WHPX.  Both do not support -cpu in any meaningful way, at least WHPX
installs a migration blocker.

Paolo

On Tue, Jun 26, 2018 at 07:57:18AM +0200, Paolo Bonzini wrote:
> On 25/06/2018 21:51, Eduardo Habkost wrote:
> > In either case, I'm not arguing (yet) for changing the default
> > upstream.  I'm just arguing for upstream QEMU to not make any
> > promises about the default.
> 
> It would be a guest ABI breakage for TCG guests, so it would only apply
> to new machine types.  I don't think it's worth the complication.

That's exactly the point: I want to stop promising a stable guest
ABI when the accelerator is omitted, because I see no benefit in
wasting energy on this.

(I don't think we ever kept the guest ABI correctly with TCG, by
the way.)


> 
> BTW, another thing that needs documenting is ABI promises for HAX and
> WHPX.  [...]

Absolutely.

-- 
Eduardo

On 26/06/2018 14:29, Eduardo Habkost wrote:
> On Tue, Jun 26, 2018 at 07:57:18AM +0200, Paolo Bonzini wrote:
>> On 25/06/2018 21:51, Eduardo Habkost wrote:
>>> In either case, I'm not arguing (yet) for changing the default
>>> upstream.  I'm just arguing for upstream QEMU to not make any
>>> promises about the default.
>>
>> It would be a guest ABI breakage for TCG guests, so it would only apply
>> to new machine types.  I don't think it's worth the complication.
> 
> That's exactly the point: I want to stop promising a stable guest
> ABI when the accelerator is omitted, because I see no benefit in
> wasting energy on this.

On the other hand I see no benefit in changing a default that people are
obviously not using (since most people use KVM, not TCG).  Distros will
keep shipping, and people will keep using qemu-kvm even if we change the
default.

> (I don't think we ever kept the guest ABI correctly with TCG, by
> the way.)

It would not be any different from KVM.  Less tested and likely to be
more buggy, yes, but not particularly harder.

Paolo

On Tue, Jun 26, 2018 at 03:05:33PM +0200, Paolo Bonzini wrote:
> On 26/06/2018 14:29, Eduardo Habkost wrote:
> > On Tue, Jun 26, 2018 at 07:57:18AM +0200, Paolo Bonzini wrote:
> >> On 25/06/2018 21:51, Eduardo Habkost wrote:
> >>> In either case, I'm not arguing (yet) for changing the default
> >>> upstream.  I'm just arguing for upstream QEMU to not make any
> >>> promises about the default.
> >>
> >> It would be a guest ABI breakage for TCG guests, so it would only apply
> >> to new machine types.  I don't think it's worth the complication.
> > 
> > That's exactly the point: I want to stop promising a stable guest
> > ABI when the accelerator is omitted, because I see no benefit in
> > wasting energy on this.
> 
> On the other hand I see no benefit in changing a default that people are
> obviously not using (since most people use KVM, not TCG).  Distros will
> keep shipping, and people will keep using qemu-kvm even if we change the
> default.

Not changing the default is different from promising we will keep
ABI compatibility if the accelerator is omitted.  I just want to
get rid of the latter.


> > (I don't think we ever kept the guest ABI correctly with TCG, by
> > the way.)
> 
> It would not be any different from KVM.  Less tested and likely to be
> more buggy, yes, but not particularly harder.

We can keep trying to not break it when "-accel tcg" is
explicitly provided.

-- 
Eduardo

On Tue, Jun 26, 2018 at 01:06:23PM -0300, Eduardo Habkost wrote:
> On Tue, Jun 26, 2018 at 03:05:33PM +0200, Paolo Bonzini wrote:
> > On 26/06/2018 14:29, Eduardo Habkost wrote:
> > > On Tue, Jun 26, 2018 at 07:57:18AM +0200, Paolo Bonzini wrote:
> > >> On 25/06/2018 21:51, Eduardo Habkost wrote:
> > >>> In either case, I'm not arguing (yet) for changing the default
> > >>> upstream.  I'm just arguing for upstream QEMU to not make any
> > >>> promises about the default.
> > >>
> > >> It would be a guest ABI breakage for TCG guests, so it would only apply
> > >> to new machine types.  I don't think it's worth the complication.
> > > 
> > > That's exactly the point: I want to stop promising a stable guest
> > > ABI when the accelerator is omitted, because I see no benefit in
> > > wasting energy on this.
> > 
> > On the other hand I see no benefit in changing a default that people are
> > obviously not using (since most people use KVM, not TCG).  Distros will
> > keep shipping, and people will keep using qemu-kvm even if we change the
> > default.
> 
> Not changing the default is different from promising we will keep
> ABI compatibility if the accelerator is omitted.  I just want to
> get rid of the latter.

I guess the key question is what is the risk of causing problems if we
switch from tcg to kvm:tcg when accelerator is omitted ?

Based on what I've seen the likely troublespot would be people who are
using QEMU inside a guest with nested-virt enabled. Some nested-virt
impls are buggy and will cause L2 guest hangs, or worse L1 host crashes.
Then again we're not causing that brokenness - just revealing what
already exists.


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 :|

On 26/06/2018 18:06, Eduardo Habkost wrote:
>> On the other hand I see no benefit in changing a default that people are
>> obviously not using (since most people use KVM, not TCG).  Distros will
>> keep shipping, and people will keep using qemu-kvm even if we change the
>> default.
>
> Not changing the default is different from promising we will keep
> ABI compatibility if the accelerator is omitted.  I just want to
> get rid of the latter.

I understand; what I don't understand is why do the latter unless you
plan to change the default.

Paolo

On Wed, Jun 27, 2018 at 10:39:29AM +0200, Paolo Bonzini wrote:
> On 26/06/2018 18:06, Eduardo Habkost wrote:
> >> On the other hand I see no benefit in changing a default that people are
> >> obviously not using (since most people use KVM, not TCG).  Distros will
> >> keep shipping, and people will keep using qemu-kvm even if we change the
> >> default.
> >
> > Not changing the default is different from promising we will keep
> > ABI compatibility if the accelerator is omitted.  I just want to
> > get rid of the latter.
> 
> I understand; what I don't understand is why do the latter unless you
> plan to change the default.

Why should we make a compatibility promise if we don't have to?
Making and keeping promises have a cost, and I'd like us to spend
our energy elsewhere.

-- 
Eduardo

On 25.06.2018 20:26, Paolo Bonzini wrote:
> On 25/06/2018 19:30, Eduardo Habkost wrote:
>>>> Attentive distros could even replace the wrapper script by a link.
>>> If they are okay with replacing the "KVM only" semantics with "KVM or
>>> TCG", which I think is generally worse.
>>
>> If we can't get agreement on what's the right default for each
>> QEMU binary, I think that's yet another reason to document that
>> upstream QEMU won't guarantee ABI compatibility if -accel is
>> omitted.
> 
> Before that we should ask what the benefit is in changing the default
> for qemu-system-*.  Nobody is using it in practice to start QEMU with
> KVM enabled...

That's certainly not true. I've seen a couple of times already that
people ask on IRC why their guests are running so slow, and if you ask
them about their command line, it's obvious that they simply were not
aware of "-accel" / "-enable-kvm" yet.

<semi-sarcastic>
Maybe we simply should add a "--verbose" command line option that people
can use to diagnose their problems:

$ qemu-system-x86_64 --verbose
QEMU emulator version 2.12.50
Using 'tcg' accelerator. Use '-accel kvm' to speed things up.
Machine type is 'pc-i440fx-3.0'. Use 'q35' for a more modern machine.
....
</semi-sarcastic>

 Cheers,
  Thomas

On Tue, 26 Jun 2018 06:40:56 +0200
Thomas Huth <thuth@redhat.com> wrote:

> On 25.06.2018 20:26, Paolo Bonzini wrote:
> > On 25/06/2018 19:30, Eduardo Habkost wrote:  
> >>>> Attentive distros could even replace the wrapper script by a link.  
> >>> If they are okay with replacing the "KVM only" semantics with "KVM or
> >>> TCG", which I think is generally worse.  
> >>
> >> If we can't get agreement on what's the right default for each
> >> QEMU binary, I think that's yet another reason to document that
> >> upstream QEMU won't guarantee ABI compatibility if -accel is
> >> omitted.  
> > 
> > Before that we should ask what the benefit is in changing the default
> > for qemu-system-*.  Nobody is using it in practice to start QEMU with
> > KVM enabled...  
> 
> That's certainly not true. I've seen a couple of times already that
> people ask on IRC why their guests are running so slow, and if you ask
> them about their command line, it's obvious that they simply were not
> aware of "-accel" / "-enable-kvm" yet.
> 
> <semi-sarcastic>
> Maybe we simply should add a "--verbose" command line option that people
> can use to diagnose their problems:
> 
> $ qemu-system-x86_64 --verbose
> QEMU emulator version 2.12.50
> Using 'tcg' accelerator. Use '-accel kvm' to speed things up.
> Machine type is 'pc-i440fx-3.0'. Use 'q35' for a more modern machine.
> ....
> </semi-sarcastic>

Not sure how serious you meant that, but I actually quite like the
idea :)

On Tue, Jun 26, 2018 at 09:50:04AM +0200, Cornelia Huck wrote:
> On Tue, 26 Jun 2018 06:40:56 +0200
> Thomas Huth <thuth@redhat.com> wrote:
> 
> > On 25.06.2018 20:26, Paolo Bonzini wrote:
> > > On 25/06/2018 19:30, Eduardo Habkost wrote:  
> > >>>> Attentive distros could even replace the wrapper script by a link.  
> > >>> If they are okay with replacing the "KVM only" semantics with "KVM or
> > >>> TCG", which I think is generally worse.  
> > >>
> > >> If we can't get agreement on what's the right default for each
> > >> QEMU binary, I think that's yet another reason to document that
> > >> upstream QEMU won't guarantee ABI compatibility if -accel is
> > >> omitted.  
> > > 
> > > Before that we should ask what the benefit is in changing the default
> > > for qemu-system-*.  Nobody is using it in practice to start QEMU with
> > > KVM enabled...  
> > 
> > That's certainly not true. I've seen a couple of times already that
> > people ask on IRC why their guests are running so slow, and if you ask
> > them about their command line, it's obvious that they simply were not
> > aware of "-accel" / "-enable-kvm" yet.
> > 
> > <semi-sarcastic>
> > Maybe we simply should add a "--verbose" command line option that people
> > can use to diagnose their problems:
> > 
> > $ qemu-system-x86_64 --verbose
> > QEMU emulator version 2.12.50
> > Using 'tcg' accelerator. Use '-accel kvm' to speed things up.
> > Machine type is 'pc-i440fx-3.0'. Use 'q35' for a more modern machine.
> > ....
> > </semi-sarcastic>
> 
> Not sure how serious you meant that, but I actually quite like the
> idea :)

Also, this mode could be enabled by default if stderr is a tty.

-- 
Eduardo

Eduardo Habkost <ehabkost@redhat.com> writes:

> On Tue, Jun 26, 2018 at 09:50:04AM +0200, Cornelia Huck wrote:
>> On Tue, 26 Jun 2018 06:40:56 +0200
>> Thomas Huth <thuth@redhat.com> wrote:
>> 
>> > On 25.06.2018 20:26, Paolo Bonzini wrote:
>> > > On 25/06/2018 19:30, Eduardo Habkost wrote:  
>> > >>>> Attentive distros could even replace the wrapper script by a link.  
>> > >>> If they are okay with replacing the "KVM only" semantics with "KVM or
>> > >>> TCG", which I think is generally worse.  
>> > >>
>> > >> If we can't get agreement on what's the right default for each
>> > >> QEMU binary, I think that's yet another reason to document that
>> > >> upstream QEMU won't guarantee ABI compatibility if -accel is
>> > >> omitted.  
>> > > 
>> > > Before that we should ask what the benefit is in changing the default
>> > > for qemu-system-*.  Nobody is using it in practice to start QEMU with
>> > > KVM enabled...  
>> > 
>> > That's certainly not true. I've seen a couple of times already that
>> > people ask on IRC why their guests are running so slow, and if you ask
>> > them about their command line, it's obvious that they simply were not
>> > aware of "-accel" / "-enable-kvm" yet.
>> > 
>> > <semi-sarcastic>
>> > Maybe we simply should add a "--verbose" command line option that people
>> > can use to diagnose their problems:
>> > 
>> > $ qemu-system-x86_64 --verbose
>> > QEMU emulator version 2.12.50
>> > Using 'tcg' accelerator. Use '-accel kvm' to speed things up.
>> > Machine type is 'pc-i440fx-3.0'. Use 'q35' for a more modern machine.
>> > ....
>> > </semi-sarcastic>
>> 
>> Not sure how serious you meant that, but I actually quite like the
>> idea :)
>
> Also, this mode could be enabled by default if stderr is a tty.

It could be enabled by default, period.

Our inability to change defaults that have become sub-optimal for most
users is depressing.

On 26/06/2018 18:43, Markus Armbruster wrote:
>>> Not sure how serious you meant that, but I actually quite like the
>>> idea :)
>> Also, this mode could be enabled by default if stderr is a tty.
> It could be enabled by default, period.

I agree, summarizing the configuration to stderr on startup is a good
idea and it shouldn't be a problem for backwards compatibility.  Doing
it only if it is a tty could be a good idea though, at least initially.

Paolo