From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55394) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bs4Kc-0004xN-6W for qemu-devel@nongnu.org; Thu, 06 Oct 2016 04:47:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bs4KZ-0002GK-Cr for qemu-devel@nongnu.org; Thu, 06 Oct 2016 04:47:09 -0400 Date: Thu, 6 Oct 2016 19:46:45 +1100 From: David Gibson Message-ID: <20161006084645.GP18733@umbus.fritz.box> References: <1475722987-18644-1-git-send-email-david@gibson.dropbear.id.au> <1475722987-18644-3-git-send-email-david@gibson.dropbear.id.au> <4490e7a0-439c-7f0a-d41d-3eb533ebb1c8@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QKpLca3blcvhMJ0W" Content-Disposition: inline In-Reply-To: <4490e7a0-439c-7f0a-d41d-3eb533ebb1c8@redhat.com> Subject: Re: [Qemu-devel] [RFC 2/4] spapr: Adjust placement of PCI host bridge to allow > 1TiB RAM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laurent Vivier Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, benh@kernel.crashing.org, thuth@redhat.com, agraf@suse.de, mst@redhat.com, aik@ozlabs.ru, mdroth@linux.vnet.ibm.com, nikunj@linux.vnet.ibm.com, bharata@linux.vnet.ibm.com, abologna@redhat.com, mpolednik@redhat.com --QKpLca3blcvhMJ0W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 06, 2016 at 09:21:56AM +0200, Laurent Vivier wrote: >=20 >=20 > On 06/10/2016 05:03, David Gibson wrote: > > Currently the default PCI host bridge for the 'pseries' machine type is > > constructed with its IO windows in the 1TiB..(1TiB + 64GiB) range in > > guest memory space. This means that if > 1TiB of guest RAM is specifie= d, > > the RAM will collide with the PCI IO windows, causing serious problems. > >=20 > > Problems won't be obvious until guest RAM goes a bit beyond 1TiB, becau= se > > there's a little unused space at the bottom of the area reserved for PC= I, > > but essentially this means that > 1TiB of RAM has never worked with the > > pseries machine type. > >=20 > > This patch fixes this by altering the placement of PHBs on large-RAM VM= s. > > Instead of always placing the first PHB at 1TiB, it is placed at the ne= xt > > 1 TiB boundary after the maximum RAM address. > >=20 > > Technically, this changes behaviour in a migration-breaking way for > > existing machines with > 1TiB maximum memory, but since having > 1 TiB > > memory was broken anyway, this seems like a reasonable trade-off. >=20 > Perhaps you can add an SPAPR_COMPAT_XX property with PHB0 base to not > break compatibility? I think spapr without PCI card (only VIO, for > instance), should work with 1TiB+. No, it won't because we always create the default PHB even if we don't actually have any PCI devices. > On another side, how the SPAPR kernel manages memory? > Is it possible to add an hole in RAM between 1TiB and 1TiB+64GiB to > allow the kernel to register the I/O space? Possible, yes, but I don't really see any advantage to it. --=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 --QKpLca3blcvhMJ0W Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJX9g91AAoJEGw4ysog2bOSBOYP/jvIptNBVHPO2/ZduGXs+TIi p/s0bbfHu7n7QWWXY8MY7yC163io9emJSG7axxmMihYBDuD+vtkcFy6XNBwkGjj6 xkGq0DaDY3wmsPO6gEkdSs4zlVZu7xlqayaMFIkLlrTxhJLDS7/RD79OfU+5ZmQa O34jFDOEdM9fi2dXFh951aFYNlbNf1b8hbAvkxZ6iYPqjgXZ73HnrNL5zNepG+3p apDGLumD6iY9D2QYCgz8WFzNvGZLWGR9769mIZMUK4X3GWWWj5bM7IlJPLV4fltC av3MggyQTRV0jKoa8XC+vNuY+Qza0M4wrCTWNqdn0eXSvQdNj7DK3V24+WgPoyav ec1Evl5FuimCgz0GZaKgvnuUwncmAjhDvzQTGGqKeIW4z6vq+MsYFxvr9wPvuMLh p6/p3+kmVddR+0y5ltFNFLjzBlhqPcEUmZES5tojCgyLrUH/h6KWAANfWsAbg6QL 2rRfkcerTzsyXiMSGkPddrKTN8pSZTsW27nH6aSAI3/FxIAfVIboFK3TUBl04lPk Pf6vmLdsiYxV4OZv3Jc2OFJoy4lIc/WRmU7Qfe5vvTiUWbHroZgHAObgg7O/jv6z e+4xvAytMoPY9vxDEXpwrBJ5Wvh5tE7PzMZneRyqi5W8UH0Dz2iGI1eMW/yZRxyI cb3Bn4+NW1traRL3FDHX =cBAG -----END PGP SIGNATURE----- --QKpLca3blcvhMJ0W--