From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bZE8g-0005kF-LY for qemu-devel@nongnu.org; Mon, 15 Aug 2016 05:24:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bZE8e-0005gE-Kr for qemu-devel@nongnu.org; Mon, 15 Aug 2016 05:24:57 -0400 Message-ID: <1471253087.3003.3.camel@redhat.com> From: Andrea Bolognani Date: Mon, 15 Aug 2016 11:24:47 +0200 In-Reply-To: References: <1469723896-28049-1-git-send-email-wei@redhat.com> <20160729065453.qq44y2hxohizk3yw@hawk.localdomain> <1470053099.3971.11.camel@redhat.com> <20160801130808.2igpsx52opi7ogvk@kamzik.localdomain> <1470058019.3971.13.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC 1/1] arm64: add an option to turn on/off vpmu support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wei Huang , Peter Maydell Cc: Andrew Jones , qemu-arm , QEMU Developers , Shannon Zhao On Sat, 2016-08-13 at 01:06 -0500, Wei Huang wrote: > > > Wouldn't that mean that you'd be unable to use > > >=C2=A0 > > >=C2=A0=C2=A0=C2=A0-cpu foo,pmu=3Doff > > >=C2=A0 > > > if CPU model 'foo' doesn't support a PMU? I'd expect that > > > to work. > >=C2=A0 > > The current precedent (has_el3) doesn't work like that: if > > foo isn't a CPU which can support EL3 then the property doesn't > > exist, and it's an error to try to set it. >=C2=A0 > V1 sent. I tried to follow everyone's advice. See the following: >=C2=A0 > * set default pmu=3Doff > * like el3, add a new feature ARM_FEATURE_HOST_PMU > * "pmu" property becomes CPU dependent. Only cortex-a53/cortex-a57/host > under certain mode support this option > * change struct ARMCPU field name "has_pmu" =3D=3D> "has_host_pmu" beca= use > IMO "has_pmu" is misleading >=C2=A0 > BTW answering Andrea's question above: "-cpu foo,pmu=3Doff" won't be > allowed in this patch if CPU "foo" doesn't support host-backed PMU. QEM= U > will fail to run in this case. Maybe this is what we want? After discussing this a bit offline, I came to the conclusion that there isn't a Single Right Way=E2=84=A2 to handle this - both my proposal and what you implemented are reasonable behaviors one could expect. On the other hand, what you implemented: =C2=A0 * matches x86 =C2=A0 * is more strict than what I proposed, so there's room to =C2=A0=C2=A0=C2=A0=C2=A0change it later without breaking any existing gue= st so I'm happy with it :) --=C2=A0 Andrea Bolognani / Red Hat / Virtualization