From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4cph-0001ZO-DA for qemu-devel@nongnu.org; Thu, 03 Dec 2015 17:58:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4cpc-0005qL-Ds for qemu-devel@nongnu.org; Thu, 03 Dec 2015 17:58:37 -0500 Message-ID: <1449183505.13462.9.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Fri, 04 Dec 2015 09:58:25 +1100 In-Reply-To: <20151203014530.GH3107@voom.redhat.com> 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> <20151203014530.GH3107@voom.redhat.com> 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: David Gibson , Alexey Kardashevskiy Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org On Thu, 2015-12-03 at 12:45 +1100, David Gibson wrote: >=20 > There are several different cases here and I'm not sure which you're > thinking about. >=20 > 1) Guest has different number of threads-per-core than the host >=20 > This one is just fine - PAPR defines how the guest should get the > number of threads from the device tree, and qemu sets that correctly. >=20 > 2) Guest threads-per-core not a power of two >=20 > The PAPR thread mechanism allows this to be communicated to the guest, > and I don't know if PAPR explicitly permits or prohibitis this > situation.=C2=A0=C2=A0Guests could get confused by it, although that's = arguably > a guest bug. Linux only supports powers of 2 =C2=A0.../... > > For now, if possible, I'd suggest implementing -nodefaults with no de= faults > > whatsoever and create a config somewhere in the qemu tree to pass it = via > > -readconfig to get reasonably configured machine so people will know = what is > > expected to work but there will still be possibility for experiments = (do not > > we secretly hope that other vendors will start designing/manufacturin= g their > > ppc64 chips?). It could be a config file per an actual POWER8 chip (w= e have > > two already). >=20 > I can see some benefit to that approach, but it does stray away from > current qemu practice (in general, not just compared to spapr). > Hmm.. not sure. I don't see an urgent need. We can do that in a separate series if we want to. As I said in another email, I don't want powernv to be "set in stone" in term of ABIs & migration for a while, so we have latitude to play with the model for a while before we lock things down. At least until after P9. > What I do think would be a good idea is to represent a POWER8 "chip" > as a instantiable qdev device, which will create the scoms and PHBs > under itself as per the hardware.=C2=A0=C2=A0We can add device properti= es as > needed to make that construction more flexible. It would also instanciate the CPUs. I want to change that in the current model, just haven't got to it yet. > We probably don't want to link the number of CPUs to the chip qdevs, > partly because that doesn't really fit the qemu model, but also > because we'll probably want some extra flexibility.=C2=A0=C2=A0e.g. mak= ing a UP > system for experimentation, even though a single chip would have > multiple cores (IIUC) - SMP TCG is super slow, so we probably want that. We want to eventually represent the EX units properly on XSCOM (the cores). So we will need that tie between chip and CPU. But we don't have to mark all cores in a chip as "enabled". It's ok to have chips with only one good core for example. Cheers, Ben.