[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
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
Paolo
- Re: [Qemu-devel] QEMU 3.0 ?, (continued)
- Re: [Qemu-devel] QEMU 3.0 ?, Paolo Bonzini, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Thomas Huth, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Paolo Bonzini, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Cornelia Huck, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Paolo Bonzini, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Cornelia Huck, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Daniel P. Berrange, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Paolo Bonzini, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Daniel P. Berrange, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Paolo Bonzini, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?,
Paolo Bonzini <=
- Re: [Qemu-devel] QEMU 3.0 ?, Cornelia Huck, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Paolo Bonzini, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Peter Maydell, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Paolo Bonzini, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Daniel P. Berrange, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Peter Maydell, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Thomas Huth, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Paolo Bonzini, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ?, Igor Mammedov, 2017/11/23
- Re: [Qemu-devel] QEMU 3.0 ? (was: [PATCH for-2.12 v3 01/11] spapr: add pseries 2.12 machine type), Daniel P. Berrange, 2017/11/23