On 8 August 2013 19:39, Christoffer Dall <christoffer.dall@xxxxxxxxxx> 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...
-- PMM
--
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
