On Thu, Aug 08, 2013 at 12:29:07PM -0700, Christoffer Dall wrote: > 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? FWIW, this is how it works on x86: QEMU calls GET_SUPPORTED_CPUID and then uses the result on a SET_CPUID call. (Well, at least that's the general idea, but the details are a bit more complicated than that. e.g.: some features can be enabled only if some QEMU options are set as well, like tsc-deadline and x2apic, that require the in-kernel irqchip to be enabled.) Even if you don't really need this 2-step method today, doing this would allow QEMU to fiddle with some bits if necessary in the future. -- Eduardo -- 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
