From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40404) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4clz-0007QS-0r for qemu-devel@nongnu.org; Thu, 03 Dec 2015 17:54:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4clu-0004M1-0Y for qemu-devel@nongnu.org; Thu, 03 Dec 2015 17:54:46 -0500 Message-ID: <1449183268.13462.5.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Fri, 04 Dec 2015 09:54:28 +1100 In-Reply-To: <565F953A.4020105@ozlabs.ru> References: <1447201710-10229-1-git-send-email-benh@kernel.crashing.org> <1447201710-10229-42-git-send-email-benh@kernel.crashing.org> <564A7584.5060605@ozlabs.ru> <1447720804.3729.17.camel@kernel.crashing.org> <20151201064326.GA4903@voom> <565E5656.8060200@ozlabs.ru> <1449034147.2983.25.camel@kernel.crashing.org> <565F953A.4020105@ozlabs.ru> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 41/77] ppc/pnv: Add LPC controller and hook it up with a UART and RTC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy , David Gibson Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org On Thu, 2015-12-03 at 12:04 +1100, Alexey Kardashevskiy wrote: > On 12/02/2015 04:29 PM, Benjamin Herrenschmidt wrote: > > On Wed, 2015-12-02 at 13:24 +1100, Alexey Kardashevskiy wrote: > > > > But on the whole I agree with you, since the LPC is part of the P= 8 > > > > chip, I think it makes sense to include it even with -nodefaults. > > >=20 > > > POWER8 chips all have 8 threads per core but we do not always assum= e -smt > > > ...,threads=3D8, how are LPC or PHB different? > >=20 > > First, for pseries which is paravirtualized it's a different can of > > worms completely. For powernv, we *should* represent all 8 threads, > > we just can't yet due to TCG limitations. >=20 > Out of curiosity - for pseries we should not?=20 Not that we should not, more like, it makes sense to offer whatever choice, it would be indeed better to have the ability to support them however. > I know it works with various=C2=A0 > numbers of threads but is not that because we also control guest linux=C2= =A0 > kernel and, for example, the Other OS (AIX) might be upset on=C2=A0 > non-multiply-of-2 number of threads? Quite possibly. I have some plans to add threads support, just haven't got to it yet :-) >=20 > > > PHB is more interesting - how is the user supposed to add more? > >=20 > > That's an open question. Since we model a real P8 chip we can only > > model the PHBs as they exist on it, which is up to 3 per chip at > > very specific XSCOM addresses. We could try to model some non-existin= g > > P8 chip with more but bad things will happen when the FW try to assig= n > > interrupt numbers for example. > =C2=A0> > > We simulate a machine that has been primed by HostBoot before OPAL > > starts. So we rely on what the device-tree tells us of what PHB were > > enabled but appart from that, we have to stick to the limitations. > =C2=A0> > > > And there always will be the default one > > > which properties are set in a separate way (via -global, not -devic= e). I > > > found it sometime really annoying to debug the existing pseries whi= ch > > > always adds a default PHB (I know, this was to make libvirt happy b= ut this > > > is not the case here). > > >=20 > > > Out of curiosity - if we have 2 chips, will the system work if the = second > > > chip does not get any LPC or PHB attached? > >=20 > > This is something I need to look into, there's a lot of work needed t= o > > properly model "chips" that I haven't done yet, but what is there is > > sufficient for a lot of usages already. >=20 > For now, if possible, I'd suggest implementing -nodefaults with no defa= ults=C2=A0 > whatsoever and create a config somewhere in the qemu tree to pass it vi= a=C2=A0 > -readconfig to get reasonably configured machine so people will know wh= at=C2=A0 > is expected to work but there will still be possibility for experiments= (do=C2=A0 > not we secretly hope that other vendors will start designing/manufactur= ing=C2=A0 > their ppc64 chips?). It could be a config file per an actual POWER8 chi= p=C2=A0 > (we have two already). There could be, but we'd need ways to specify a bunch of things, it's not that trivial. IE, the xscom addresses of the 3 ranges for each PHB for example etc.. For now let's keep things simple. I also am in no hurry to support migration with powernv, so we have quite a bit of flexibility to change things. Cheers, Ben.