Alexander Graf <ag...@suse.de> writes: > On 03.10.2012, at 22:26, Peter Maydell wrote: > >> On 3 October 2012 21:01, Blue Swirl <blauwir...@gmail.com> wrote: >>> On Mon, Oct 1, 2012 at 4:20 PM, Anthony Liguori <anth...@codemonkey.ws> >>> wrote: >>>> Jan Kiszka <jan.kis...@siemens.com> writes: >>>>> + /* The default accelerator depends on the availability of KVM. */ >>>>> + p = kvm_configured ? "kvm" : "tcg"; >>>>> } >> >>>> Blue/Aurelien, any objections? >>> >>> No, maybe a message could be printed that says that the default has >>> changed, for a few releases. >> >> I've lost track of the conversation, are we currently proposing >> the accelerator default to be "kvm" (as per the original patch >> you quote here) or "kvm:tcg" ? >> >> I'm not entirely sure which I prefer from an ARM perspective >> For some time to come and for a lot of targets (ie any target >> CPU except A15), having a default of "kvm" is going to cause >> existing working commandlines to stop working. [I expect that >> ARM-host qemu binaries will be built with CONFIG_KVM once ARM >> KVM support lands, but the same binary will be run on hosts >> without virtualization extensions.] On the other hand, perhaps >> there just aren't really very many people who run QEMU on >> ARM hosts, and so we can ignore them :-) > > We get similar problems on PPC. Take the following example: > > $ qemu-system-ppc -M mpc8544ds -kernel uImage -nographic
But do you really expect people to do this? I have to believe that people running on PPC hardware and running qemu-system-ppc most likely want to do KVM... Kernel development seems unlikely... The folks that I know doing PPC kernel development with QEMU still qemu-system-ppc on x86. Regards, Anthony Liguori > > That command line would work just fine if you run it on a G5 today. However, > if we switch to accel=kvm:tcg, it will stop working, because kvm on the G5 > can not virtualize an e500 CPU. > > I don't know any good way around that one either the way the code is layered > today. We only know the type of CPU we want to create after we made the > decision whether we do KVM or not. > > > Alex
