On Thu, 23 Nov 2017 14:02:12 +0100
Paolo Bonzini <pbonz...@redhat.com> wrote:
> On 23/11/2017 13:39, Cornelia Huck wrote:
> > I'm wondering how many people want to run e.g. x86_64-on-x86_64
> > _without_ using an available kvm (and I expect those people to
> > explicitly specify tcg).
>
> I disagree. I expect them to be "power users" enough to know that
> qemu-system-x86_64 defaults to TCG.
Do we have any idea (from questions, bugzillas, ...) about which kind
of people actually do that?
[Coming from s390x, where tcg cannot run most current distros, I'm
lacking data.]
>
> Another possibility is that users come here asking for help, we tell
> them to test qemu.git, and they are confused by the lack of a qemu-kvm
> binary. Ok, maybe not that likely, but it's a category which we want to
> have a smooth experience.
>
> >> And in fact that is the main reason why have never bothered switching
> >> the default... only RHEL does it, because it ships the QEMU binary as
> >> qemu-kvm rather than qemu-system-xxx plus a wrapper script.
> >>
> >> Perhaps we could:
> >>
> >> 1) look for "qemu-{kvm,hvf,hax}" in argv[0] and change the "-accel"
> >> default?
> >>
> >> 2) change "make install" to install one or more of qemu-kvm/hvf/hax
> >> based on target architecture and OS.
> >>
> >> Then distros can do away with the script and Windows/Mac users can learn
> >> to use qemu-hvf and qemu-hax.
> >
> > I'm not sure I like that. For me, qemu-kvm comes with the connotation
> > of "there used to be a fork of qemu for kvm usage, and we stuck with
> > the name because it is likely scattered through scripts".
>
> In theory I don't like it either (and I hadn't thought about it until
> today). In practice, qemu-kvm is not going away from
> blogs/scripts/tutorials in a decade, so we might as well embrace it...
> especially since it has fewer issues than the alternative and even some
> advantages:
>
> 1) scripts that hardcode qemu-system-x86_64 expecting to use TCG keep to
> work
>
> 2) it ensures that qemu-kvm works even for those who compile their own QEMU
>
> 3) it keeps behavior consistent across all qemu-system-* binaries
>
> 4) it reserves the unwieldy name for the thing that you don't want
> (think of "exit" vs "_exit" in the C library)
>
> 5) we don't have to think about including hax or hvf in the -accel default
One issue I see is that this naming convention only works with
same-architecture accelerators. You can't have a qemu-tcg as you don't
know which architecture is supposed to be emulated. (Or if you use
qemu-tcg as a shorthand for same-architecture emulation, you still have
the long names for anything else, which is even more confusing.)
