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

[Christoffer Dall]

On Thu, Aug 08, 2013 at 09:48:23PM +0100, Peter Maydell wrote:
> 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.)
> 

ok, fair enough, as long as you can get what you need from the MIDR then
you're good I guess.

> > 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.

I'm fine with having a discovery mechanism for the GIC and not for the
CPU, if there's an implicit discovery mechanism for the CPU.  But are
we sure there will not be cases where we want to know the list of
available CPUs that the kernel can actually emulate on this host as
opposed to "just use the best one".  Maybe that's only relevant for the
"give me an A15 case" and then you can just do trial-and-error, perhaps.

-Christoffer