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: Christoffer Dall
Subject: Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06)
Date: Thu, 8 Aug 2013 11:39:35 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Aug 08, 2013 at 07:20:41PM +0100, Peter Maydell wrote:
> On 8 August 2013 16:55, Andreas Färber <address@hidden> wrote:
> > Am 08.08.2013 14:51, schrieb Peter Maydell:
> >> So, coming at this from an ARM perspective:
> >> Should any target arch that supports KVM also support "-cpu host"?
> >> If so, what should it do?
> >
> > I think that depends on the target and whether/what is useful.
> 
> The most immediate problem we have is we don't want to have
> to give QEMU a lot of info about v8 CPUs which it doesn't
> really need to have just in order to start a VM; I think
> -cpu host would fix that particular problem.
> 
> >> Is there a description somewhere of
> >> what the x86 and PPC semantics of -cpu host are?
> >
> > I'm afraid our usual documentation will be reading the source code. ;)
> >
> > x86 was first to implement -cpu host and passed through pretty much all
> > host features even if they would not work without additional support
> > code. I've seen a bunch of bugs where that leads to GMP and others
> > breaking badly. Lately in the case of PMU we've started to limit that.
> > Alex proposed -cpu best, which was never merged to date. It was similar
> > to how ppc's -cpu host works:
> >
> > ppc matches the Processor Version Register (PVR) in kvm.c against its
> > known models from cpu-models.c (strictly today, mask being discussed).
> > The PVR can be read from userspace via mfpvr alias to mfspr (Move From
> > Special Purpose Register; possibly emulated for userspace by kernel?).
> > CPU features are all QEMU-driven AFAIU, through the "CPU families" in
> > translate_init.c. Beware, everything is highly macro'fied in ppc code.
> 
> In theory we could do a similar thing for ARM (pull the CPU
> implementer/part numbers out of cpuinfo and match them against
> QEMU's list of known CPUs). However that means you can't run
> KVM on a CPU which QEMU doesn't know about, which was one
> of the reasons for the approach I suggested below.
> 
> >> For ARM you can't get at feature info of the host from userspace
> >> (unless you want to get into parsing /proc/cpuinfo), so my current
> >> idea is to have KVM_ARM_VCPU_INIT support a target-cpu-type
> >> which means "whatever host CPU is". Then when we've created the
> >> vcpu we can populate QEMU's idea of what the CPU features are
> >> by using the existing ioctls for reading the cp15 registers of
> >> the vcpu.
> >
> > Sounds sane to me iff those cp15 registers all work with KVM and don't
> > need any additional KVM/QEMU/device code.
> 
> Yes; KVM won't tell us about CP15 registers unless they
> are exposed to the guest VM (that is, we're querying the
> VCPU, not the host CPU). More generally, the cp15 "tuple
> list" code I landed a couple of months back makes the kernel
> the authoritative source for which cp15 registers exist and
> what their values are -- in -enable-kvm mode QEMU no longer
> cares about them (its own list of which registers exist for
> which CPU is used only for TCG).
> 
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.

-Christoffer



reply via email to

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