On Thu, Aug 08, 2013 at 08:05:11PM +0100, Peter Maydell wrote: > 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... > 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 -- 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
