qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 0/2] target-arm: Provide '-cpu host' when running


From: Peter Maydell
Subject: Re: [Qemu-devel] [RFC 0/2] target-arm: Provide '-cpu host' when running KVM
Date: Wed, 14 Aug 2013 10:06:13 +0100

On 14 August 2013 07:32, Alexander Graf <address@hidden> wrote:
>
> On 13.08.2013, at 20:03, Peter Maydell wrote:
>
>> These patches add support to target-arm for '-cpu host'.
>> The general semantics are the same as for ppc and x86 (ie "whatever
>> the host kernel can support that looks basically like the host
>> CPU"), but the mechanism is a little different.
>>
>> The kernel API (currently still proposed rather than implemented,
>> hence the RFC nature of this patchset) is that the existing
>> KVM_ARM_VCPU_INIT supports a new 'target' value KVM_ARM_TARGET_HOST,
>> which it treats as "whatever you are". On the userspace side,
>> we use this if the kernel supports it. If it doesn't then we
>> know the kernel must be an A15-on-A15 only one, and so can
>> safely implement '-cpu host' with KVM_ARM_TARGET_CORTEX_A15.
>
> How do you know what core specific registers QEMU can expect from
> this particular CPU?

For 99% of them we simply don't care...

> Imagine ARM changes the MMU implementation in the next ARMv8 CPU.
> With -cpu host you wouldn't be able to support gdbstub anymore,
> because you wouldn't know whether the MMU format is the old or
> the new one.

...and for the other 1% we can add a bit to the VCPU_INIT features
field saying "this QEMU can handle CPUs with $weird-new-thing"
and have the kernel fail CPU creation otherwise.

> I really prefer the "probe the host, match it fuzzily with our
> own list, pick a specific own core" way of doing -cpu host. Then
> it's really only ever an alias and you don't have to worry about
> all these odd special cases.

I really don't want to be trying to model five hundred different
CPUs inside QEMU half of which I probably won't have the
documentation for. That is just going to mean "KVM+QEMU won't
work on a lot of hardware when there is no reason it shouldn't".

-- PMM



reply via email to

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