Re: [Qemu-devel] QEMU 3.0 ?

[Cornelia Huck]

On Thu, 23 Nov 2017 14:02:12 +0100
Paolo Bonzini <address@hidden> 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.)