[Top][All Lists]

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

Re: [Qemu-devel] QEMU 3.0 ?

From: Paolo Bonzini
Subject: Re: [Qemu-devel] QEMU 3.0 ?
Date: Thu, 23 Nov 2017 14:02:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0

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.

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

1) scripts that hardcode qemu-system-x86_64 expecting to use TCG keep to

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


reply via email to

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