Re: [Qemu-trivial] [Qemu-devel] [RFC PATCH 4/4] qemu-options: Do not show -enable-kvm and -enable-hax in the docs anymore

[Paolo Bonzini]

On 25/06/2018 08:50, Markus Armbruster wrote:
> Paolo Bonzini <address@hidden> 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.