Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06)

[Peter Maydell]

On 8 August 2013 20:29, Christoffer Dall <address@hidden> wrote:
> On Thu, Aug 08, 2013 at 08:05:11PM +0100, Peter Maydell wrote:
>> On 8 August 2013 19:39, Christoffer Dall <address@hidden> wrote:
>> > FWIW, from the kernel point of view I'd much prefer to return "this is
>> > the type of VCPU that I prefer to emulate" to user space on this current
>> > host than having QEMU come up with its own suggestion for CPU and asking
>> > the kernel for it.  The reason is that it gives us slightly more freedom
>> > in how we choose to support a given host SoC in that we can say that we
>> > at least support core A on core B, so if user space can deal with a
>> > virtual core A, we should be good.
>>
>> Hmm, I'm not sure how useful a "query support" kind of API would
>> be to QEMU. QEMU is basically going to have two use cases:
>> (1) "I want an A15" [ie -cpu cortex-a15]
>> (2) "give me whatever you have and I'll cope" [ie -cpu host]
>>
>> so my thought was that we could just have the kernel support
>>     init.target = KVM_ARM_TARGET_HOST;
>>     memset(init.features, 0, sizeof(init.features));
>>     ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
>>
>> (in the same way we currently ask for KVM_ARM_TARGET_CORTEX_A15).
>>
>> I guess we could have a "return preferred target value"
>> VM ioctl, but it seems a bit pointless given that the
>> only thing userspace is going to do with the return
>> value is immediately feed it back to the kernel...
>>
> My thinking was that the result of cpu = KVM_ARM_TARGET_HOST would be
> the same as x = kvm_get_target_host(), cpu = x, but at the same time
> letting QEMU know what it's dealing with.  Perhaps QEMU doesn't need
> this for emulation, but isn't it useful for
> save/restore/migration/debugging scenarios?

For migration we don't care because we just send everything
over the wire and let the receiving kernel decide (where
it will presumably reject if the MIDR value doesn't match).

There are some cases where we want to know what kind of CPU
we actually got, though the only one I could think of was if
we're constructing a device tree for mach-virt, what do we put
in the cpu node's "compatible" property? (what does the kernel
do with that anyway?) I had planned to key that off the MIDR
value, though. (As an aside, if there was a way to get the
actual 'compatible' string from the host kernel rather than
having to maintain a table of KVM_ARM_TARGET_* and/or MIDR
to compatible-string values that would be neat.)

> So, if you just use the KVM_ARM_TARGET_HOST value, do you expect the
> kernel to just set the base address of the GIC interface, or?

So in this view of the world, we keep the GIC separate from
the CPU itself (which allows things like "give me an A57
vcpu but actually it's got a GICv2 because that's all the
host hardware/kernel can do"). The GIC base address is then
a property of the board model we're running rather than of
the CPU (and for mach-virt we just set it to something
convenient). This would be done via the new-style irqchip
creation/config API rather than what we have in tree today.
Presumably we could have a similar thing for the irqchip
of "tell me what kind of irqchip you can instantiate and/or
give me what you've got". I guess here we do need a way to
find out what the kernel can do since (a) the kernel might
be able to accelerate both GICv2 and v3 with no inherent
preference and (b) there's no handy GIC-version-register
like the MIDR we can use to track what we got. That might
argue for a similar approach for the CPU proper, by analogy.

-- PMM