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

[Christoffer Dall <christoffer.dall@linaro.org>]

On Thu, Aug 08, 2013 at 08:05:11PM +0100, Peter Maydell wrote:
> On 8 August 2013 19:39, Christoffer Dall <christoffer.dall@linaro.org> 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?

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?

-Christoffer