Re: [Qemu-devel] [PATCH] Deprecate '-enable-kvm' and '-enable-hax' in favour of '-accel'

[Daniel P. Berrange]

On Tue, May 02, 2017 at 01:16:33PM +0100, Daniel P. Berrange wrote:
> On Tue, May 02, 2017 at 02:07:15PM +0200, Thomas Huth wrote:
> > On 02.05.2017 13:59, Daniel P. Berrange wrote:
> > > On Tue, May 02, 2017 at 01:26:17PM +0200, Thomas Huth wrote:
> > >> On 02.05.2017 12:48, Christian Borntraeger wrote:
> > >>> On 05/02/2017 12:37 PM, Thomas Huth wrote:
> > >>>> On 02.05.2017 12:32, Christian Borntraeger wrote:
> > >>>>> On 05/02/2017 12:06 PM, Thomas Huth wrote:
> > >>>>>> The '-enable-...' option do not make too much sense: They do not
> > >>>>>> allow additional parameters, using '-accel xxx' is shorter than
> > >>>>>> '-enable-xxx' and we're also inconsistent here, since there is
> > >>>>>> no '-enable-xen' option available. So let's try to convince the
> > >>>>>> users to use '-accel xxx' instead.
> > >>>>>
> > >>>>> google has 36000 hits for "--enable-kvm" and 18000 hits for "--accel 
> > >>>>> kvm"
> > >>>>> So I assume this will affect a lot of setups for only a very small 
> > >>>>> benefit.
> > >>>>
> > >>>> I'm aware of the fact that likely a lot of users are still using
> > >>>> -enable-kvm, and I did not mean that we should remove it soon yet. But
> > >>>> IMHO we should start now to inform the users that they should slowly
> > >>>> switch to the better option "-accel" instead, so that we could maybe
> > >>>> remove this "-enable-xxx" stuff sometime in the distant future (let's
> > >>>> say QEMU v4.0?).
> > >>>
> > >>> I come from the Linux side, where "breaking a working setup" will 
> > >>> result in
> > >>> an angry Linus.
> > >>
> > >> IMHO that's a good approach, but I think it should primarily applied for
> > >> the interfaces that are designed as "API" to other software layers, i.e.
> > >> things like QMP and the "-machine" parameter.
> > >> "-enable-kvm" is in my eyes rather a "syntactic sugar" convenience
> > >> option, so I'd not apply this rule to this option.
> > >>
> > >>> We certainly have not such strict rules here and we could
> > >>> base the decision on the question "how expensive is the maintenance
> > >>> of this option?". I think marking it as "legacy option" is fine, but I 
> > >>> doubt
> > >>> that removing it will make qemu maintenance cheaper.
> > >>
> > >> Likely not. Actually, I have another point of view in mind here: You
> > >> have to consider that QEMU has a *lot* of options, and I think this is
> > >> very confusing for the users, especially the new ones. If we always
> > >> provide two or three ways to achieve a goal, especially in an
> > >> inconsistent way like we do it here, we likely rather create frustration
> > >> than joy for the normal users. Providing a clean, straightforward CLI
> > >> interface one day could help to improve the user experience quite a bit.
> > > 
> > > The issue is that we have mutually exclusive requirements here. For a
> > > straightforward, easy to understand CLI, things like "--enable-kvm" are
> > > much quicker to discover & understand than "-machine accel=kvm". The
> > > latter gives much more flexibility since it can set all the other opts,
> > > but most of those are rarely used by people who are invoking QEMU
> > > manually/directly. We need the things like -machine for libvirt and
> > > similar, but they are not end user friendly. Killing all the shortcuts
> > > like --enable-kvm would cut down the args we expose, but forcing users
> > > onto more complex syntax for args like -machine is not improving their
> > > lives in general if they don't need that extra flexibility.
> > 
> > Theoretically yes, but in this case we also have the "-accel kvm" option
> > which is IMHO also straighforward and easy to understand, and even
> > shorter than "-enable-kvm". If you look at my patch, I did *not* want to
> > force the normal users to use "-machine accel=kvm" here, so I don't see
> > the point of your argument here.
> 
> Just looking at the -help output though we have
> 
>   "-machine [type=]name[,prop[=value][,...]]
>                    property accel=accel1[:accel2[:...]] selects accelerator
>                    supported accelerators are kvm, xen, tcg (default: tcg)"
> 
> and
> 
>   "-enable-kvm     enable KVM full virtualization support"
> 
> but the "-accel" option is not documented, so essentially doesn't exist,
> unless you read the man page to see if there are other secret options
> listed there. So from -help output, "-enable-kvm" looks like the best
> option to pick from a novice user POV.

Opps, I was looking at wrong QEMU binary - it is listed

   "-accel [accel=]accelerator[,thread=single|multi]
               select accelerator ('-accel help for list')"

but it doesn't mention KVM, so I still think -enable-kvm is the more obvious
right answer based on what we're telling users in help


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