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

[Gleb Natapov <gleb@redhat.com>]

On Fri, Aug 09, 2013 at 02:53:30PM -0300, Eduardo Habkost wrote:
> 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@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?
> 
> 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.
> 
Without 2-step method how QEMU ARM knows that it can create cpu type
user asked for? On x86 QEMU queries kernel about what feature can be
supported and then "and" it with requested features (feature can be
requested implicitly, by specifying cpu model name like "Neahalem", or
explicitly, by adding +feature_name on -cpu parameter). -cpu host is
just a by product of this algorithm, it says enables everything that is
supported ("supported & 1" instead of "supported & requested").

--
			Gleb.