From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bzw7v-0001Yt-MN for qemu-devel@nongnu.org; Thu, 27 Oct 2016 21:38:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bzw7s-0002Uz-IX for qemu-devel@nongnu.org; Thu, 27 Oct 2016 21:38:35 -0400 Date: Fri, 28 Oct 2016 12:03:34 +1100 From: David Gibson Message-ID: <20161028010334.GC19349@umbus.fritz.box> References: <1477129610-31353-1-git-send-email-clg@kaod.org> <1477129610-31353-14-git-send-email-clg@kaod.org> <20161025053627.GC11052@umbus.fritz.box> <20161027031242.GH19918@umbus.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4jXrM3lyYWu4nBt5" Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v5 13/17] ppc/xics: add a xics_get_cpu_index_by_pir helper List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?C=E9dric?= Le Goater Cc: qemu-ppc@nongnu.org, Benjamin Herrenschmidt , qemu-devel@nongnu.org, Alexander Graf --4jXrM3lyYWu4nBt5 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 27, 2016 at 08:05:02PM +0200, C=E9dric Le Goater wrote: > On 10/27/2016 05:12 AM, David Gibson wrote: > > On Tue, Oct 25, 2016 at 12:58:11PM +0200, C=E9dric Le Goater wrote: > >> On 10/25/2016 07:36 AM, David Gibson wrote: > >>> On Sat, Oct 22, 2016 at 11:46:46AM +0200, C=E9dric Le Goater wrote: > >>>> We will need this helper to translate the server number of the XIVE > >>>> (which is a PIR) into an ICPState index number (which is a cpu index= ). > >>>> > >>>> Signed-off-by: C=E9dric Le Goater > >>> > >>> Looks correct as far as it goes, but I wonder if this would be more > >>> generally useful as a machine level function that searches the cpu > >>> objects by PIR, returning a pointer. From that to the cpu_index is > >>> then trivial. > >> > >> Well I guess so. The XICSState argument reduces the scope in case of= =20 > >> multichip but as this routine is used to initialize the xive registers= ,=20 > >> it does not need to be fast. > >=20 > > Ahh.. I was thinking of the top-level xics object as global, rather > > than per-chip. >=20 > well, the ICP MMIO region address is linked to the chip but that is all > for the moment. > =20 > > Except.. does having it per-chip work anyway? The server numbers are=20 > > globally unique, aren't they? =20 >=20 > yes. > =20 > > What happens if you put a server number from one chip as the target=20 > > for an ICE on another chip? >=20 > we have the chip number, so we could route ? I haven't gone that far > in the modeling though. It might be overly complex to do for the purpose. Right.. yeah, trying to route between XICS objects sounds like a nightmare. Really the whole notion of the XICS overall object is that it represents the whole irq propagation fabric - so it knows about all the ICPS and all the ICSes and handles the routing between them. So making the XICS object per-chip I think is a mistake which will just lead to pain down the track. See my other mail for a new suggestion on how to handle this. > > The xics object is a bit weird, in that it doesn't represent a real > > device in a sense, but is rather something to co-ordinate global > > addressing between ICS and ICP units. Well, I suppose in that sense > > it represent the interrupt propagation fabric. >=20 > yes. See my other email. I think we can get rid of it and simply use > a XICSState which links together the ICPs and the ICS of the system.=20 > but, let's keep it at the chip level for the moment, it is correct,=20 > and see if we need to move it upwards when we work on multichip. No, I disagree. I think moving the XICs up a layer will only create pain later for little benefit now. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --4jXrM3lyYWu4nBt5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYEqPmAAoJEGw4ysog2bOSij4P/i8kq+2eUILOluJeUHHnetOE bT8UhEh4050tOiH3PYChWmXpT6pY4l1H2CALsF98+ZXfS3dF5mW/vjoBtM8uwhFh z0oK4ucRI8dHCEDkl7LxEBDGG16OOCh0GKxGo3FBom8D4pBAoah8afNtds/7lk1x UkY3YjtZhFud9Z58Fp9EQMmRkJRooaAedxjnSPZ90Rov04hDdC5XzsCvkAOCN4aZ 0cpW/Vod77enymW4Ky4vw7liqIt+HqvY34QCRTKRFIz3ZQtsZi+wDn0LarhtM6+c F6DWRsw+8gxCNZy3VsleuQSysiwwySmvCK1YbEllzOxVRwFrMmZSIs3xGxMLde4Y QK3EU9jmHHiFT7Yt6fr8G3vVY5Nx1ocOpxpoMXgMcZpWjoj1z4LVoQzRyYypwSJd JeHyYxSxpq0HcJNj7U3Ja91NzKVXgRQVujRVPAdNeoNwzCsyO+L3XIqWZkZw1d66 xCii8OgeqwDE1ybqmcnIW5/DhaJJXYkGPLFOilww4M/DqIH3SHzmdmCZmJ/bu7ob eJElIY1Yaul2LsFpapaZU6vr5LT+bk02G7oP4Qp2X+uIeJh/GRyjF0q7myUtuKvR ubcD7P3FSE5BcTCBTtW7ZiN5Ogds51XpX7tKMDtrx0LFKFdiGTeKTht1NouTR3Fv /wWX27ruSaGfJyD5ux6m =hnwb -----END PGP SIGNATURE----- --4jXrM3lyYWu4nBt5--