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

[Thomas Huth]

On 02.05.2017 14:38, Daniel P. Berrange wrote:
> 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

Oh, right, that parameter has just been introduced with QEMU 2.9.0 ...
so maybe it's really too early to spill out deprecation messages for
"-enable-kvm", and we just should update the documentation instead (as
Christian suggested)...

 Thomas