From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDa9z-0000BG-Ij for qemu-devel@nongnu.org; Sun, 25 Aug 2013 09:15:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VDa9u-0007JW-Ra for qemu-devel@nongnu.org; Sun, 25 Aug 2013 09:15:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7039) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDa9u-0007JI-Ju for qemu-devel@nongnu.org; Sun, 25 Aug 2013 09:15:10 -0400 Date: Sun, 25 Aug 2013 16:14:54 +0300 From: Gleb Natapov Message-ID: <20130825131454.GQ8218@redhat.com> References: <5203BF5D.4030007@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <5203BF5D.4030007@suse.de> Subject: Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: Peter Maydell , kvmarm@lists.cs.columbia.edu, qemu-devel , KVM devel mailing list , quintela@redhat.com On Thu, Aug 08, 2013 at 05:55:09PM +0200, Andreas F=C3=A4rber wrote: > Hi Peter, >=20 > Am 08.08.2013 14:51, schrieb Peter Maydell: > > [I missed this KVM call but the stuff about -cpu host ties into > > an issue we've been grappling with for ARM KVM, so it seems > > a reasonable jumping-off-point.] > >=20 > > On 6 August 2013 16:15, Juan Quintela wrote: > >> 2013-08-06 > >> ---------- > >> > >> What libvirt needs/miss Today? > >> - how to handle machine types? creating them inside qemu? > >> - qemu --cpu help > >> only shows cpus, not what features qemu will use > >> - qemu -cpu host > >> what does this exactly means? kvm removes same flags. > >> - Important to know if migration would work. > >> - Machine types sometimes disable some feature, so cpu alone is not > >> enough. > >=20 > >> - kernel removes some features because it knows it can't be virtualised > >> - qemu adds some others because it knows it don't need host support > >> - and then lots of features in the middle > >=20 > > 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? >=20 > I think that depends on the target and whether/what is useful. >=20 > > Is there a description somewhere of > > what the x86 and PPC semantics of -cpu host are? >=20 > I'm afraid our usual documentation will be reading the source code. ;) >=20 > 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. This is definitely not true. Only features that will work are passsed throu= gh. Actually the definition of "-cpu host" for x86 can be: advertise any feature that can be supported on this host/qemu combo. > 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. The problem with PMU was that PMU capabilities was passed through even for non "-cpu host". There was no problem with "-cpu host". > Alex proposed -cpu best, which was never merged to date. It was similar > to how ppc's -cpu host works: According to http://wiki.qemu.org/Features/CPUModels#-cpu_host_vs_-cpu_best it should select predefined cpu model closest to host one. Useful, bit not the same as "-cpu host". >=20 > 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. >=20 -- Gleb.