From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9ziG-0003ts-2r for qemu-devel@nongnu.org; Thu, 15 Aug 2013 11:43:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9zi2-0003xK-5v for qemu-devel@nongnu.org; Thu, 15 Aug 2013 11:43:48 -0400 Message-ID: <520CF721.6060809@suse.de> Date: Thu, 15 Aug 2013 17:43:29 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <7AAF2DA2-1FEF-4ECA-B220-366D94EC70C4@suse.de> <1376552735-2953-1-git-send-email-aik@ozlabs.ru> <520C8C11.6080905@ozlabs.ru> <98FAFA62-3B3A-40E9-8973-705C5F569CEE@suse.de> <520CB2EC.8060105@suse.de> <471DDE4C-6C6F-4F07-BCFB-8765AC88FEF4@suse.de> <520CBFFD.5040100@suse.de> <520CDDBF.9070909@ozlabs.ru> <520CEA00.2020404@suse.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH v3] powerpc: add PVR mask support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Anthony Liguori , Alexey Kardashevskiy , qemu-devel@nongnu.org, qemu-ppc@nongnu.org, Paul Mackerras Am 15.08.2013 17:29, schrieb Alexander Graf: >=20 > On 15.08.2013, at 16:47, Andreas F=E4rber wrote: >=20 >> There is nothing wrong with finding a mask or wildcard solution to tha= t >> problem, I already indicated so on the original POWER+ patch. The poin= t >> of the whole discussion is how to get there in the least invasive way. >> Not whether, just how. >> >> I think - unlike Alex apparently - that the least invasive way is to >> leave models as they are and to add masking support to families and KV= M >> code only. >=20 > Not sure I understand. What is KVM specific about this? -cpu host is, it's in kvm.c. These patches are changing sort comparison code in translate_ppc.c though, which is used in multiple places. >=20 >> I'm already trying to get away from extending the >> POWERPC_DEF* macros for Prerna's fw_name, which are starting to get a >> big conflict point these days and a future pain if everyone extends th= em >> for the feature of the day. Note that I started with reading v3, not >> everything from the start, and am therefore not pointing fingers at >> anyone. It may be that you were given some unfortunate suggestions and >> too quick in implementing them. >> >> When we instantiate a -cpu POWER9 then having one POWER9_vX.Y around t= o >> back it doesn't really hurt. Unlike ARM's MIDR there doesn't seem to b= e >> an encoding of IBM vendor or POWER family in the PVR. The macros and >> their new implementation are not the way they are because I consider >> them the nicest thing in the world but because the name+pvr+svr+family >> combination made them work for the whole zoo of models we carry around >> and started to give us some inheritance through QOM. Making the POWER7 >> family non-abstract would require the same kind of macro "overloading" >> for POWERPC_FAMILY that I'm trying to contain for POWERPC_DEF ATM. So >> what I am still thinking about is how to handle there being multiple >> matches for a PVR - I am considering putting them into a list and >> comparing values for closest match. So that if you have a v2.4 and QEM= U >> knows v2.1 and v2.3 we take v2.3 and fill in the v2.4 PVR. >=20 > I think this goes into the wrong direction. We should have one single u= nified scheme to model core versions and -cpu host should be able to over= ride them for a family, no? I don't see how instantiating a POWER7_v20 ob= ject on a POWER7_v23 system is any improvement over instantiating a POWER= 7 object. There is no one unified scheme, as we have discussed in your absence. My point is, a) -cpu POWER7 should result in valid values and b) you asked to have a unified macro scheme that works for all CPUs, you got it, now instead you are asking for something that is nice to POWERx, and we cannot make POWERx family different from the rest wrt macros unless we break the scheme, which you specifically wanted to have, to avoid boilerplate QOM code you said. Now you want the full customization goodness that you were against just before! :) Andreas P.S. Please configure your mail client to break lines. Replying is really hard this way... --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg