qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eduardo Habkost
Subject: Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06)
Date: Fri, 9 Aug 2013 14:53:30 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

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 <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]