Re: [Qemu-devel] [PATCH] kvm: Set default accelerator to "kvm" if the host supports it

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

 



Am 05.10.2012 04:24, schrieb Alexander Graf:
> 
> On 05.10.2012, at 04:17, Anthony Liguori wrote:
> 
>> Alexander Graf <agraf@xxxxxxx> writes:
>>
>>> On 03.10.2012, at 22:26, Peter Maydell wrote:
>>>
>>>> On 3 October 2012 21:01, Blue Swirl <blauwirbel@xxxxxxxxx> wrote:
>>>>> On Mon, Oct 1, 2012 at 4:20 PM, Anthony Liguori <anthony@xxxxxxxxxxxxx> wrote:
>>>>>> Jan Kiszka <jan.kiszka@xxxxxxxxxxx> 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...
> 
> Sure. But we wouldn't be able to even tell them what went wrong, as we don't have a negotiation mechanism right now that could tell user space "hey, the CPU you selected is unknown to me".

Would it help to split out the cpu_model -> CPUClass lookup from
cpu_ppc_init() to invoke a hook or inquire a field indicating KVM support?

Andreas

> 
> However, if during cpu init we could add such a check and then fall back to tcg mode if accel=kvm:tcg with a warning, that'd be nice user experience.
> 
> We could do the same for ARM. If you do -M beagle on an A15 KVM enabled machine, you would still be able to do so, but KVM tells you it can't emulate an A8 right now. And if in the future KVM learns how to expose an A8 on A15, we could just not bail out and things would magically work.
> 
> Apart from that, I like the idea of kvm:tcg with a warning as the default for qemu. We should still have a qemu-kvm binary in the distro that does accel=kvm so people don't accidentally fall back to tcg mode.
> 
> 
> Alex
> 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux