[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-devel] [RFC PATCH 4/4] qemu-options: Do not sho

From: Eduardo Habkost
Subject: Re: [Qemu-trivial] [Qemu-devel] [RFC PATCH 4/4] qemu-options: Do not show -enable-kvm and -enable-hax in the docs anymore
Date: Mon, 25 Jun 2018 14:30:56 -0300
User-agent: Mutt/1.9.2 (2017-12-15)

On Mon, Jun 25, 2018 at 12:28:34PM +0200, Paolo Bonzini wrote:
> 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.

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]