From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNzmi-0001aX-Mo for qemu-devel@nongnu.org; Fri, 15 Jul 2016 05:51:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNzmd-0006DT-BL for qemu-devel@nongnu.org; Fri, 15 Jul 2016 05:51:51 -0400 Date: Fri, 15 Jul 2016 18:35:30 +1000 From: David Gibson Message-ID: <20160715083530.GA14615@voom.fritz.box> References: <1468570225-14101-1-git-send-email-thuth@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c1qHkdEbEbCG94PZ" Content-Disposition: inline In-Reply-To: <1468570225-14101-1-git-send-email-thuth@redhat.com> Subject: Re: [Qemu-devel] [PATCH] ppc: Yet another fix for the huge page support detection mechanism List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org --c1qHkdEbEbCG94PZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 15, 2016 at 10:10:25AM +0200, Thomas Huth wrote: > Commit 86b50f2e1bef ("Disable huge page support if it is not available > for main RAM") already made sure that huge page support is not announced > to the guest if the normal RAM of non-NUMA configurations is not backed > by a huge page filesystem. However, there is one more case that can go > wrong: NUMA is enabled, but the RAM of the NUMA nodes are not configured > with huge page support (and only the memory of a DIMM is configured with > it). When QEMU is started with the following command line for example, > the Linux guest currently crashes because it is trying to use huge pages > on a memory region that does not support huge pages: >=20 > qemu-system-ppc64 -enable-kvm ... -m 1G,slots=3D4,maxmem=3D32G -object \ > memory-backend-file,policy=3Ddefault,mem-path=3D/hugepages,size=3D1G,i= d=3Dmem-mem1 \ > -device pc-dimm,id=3Ddimm-mem1,memdev=3Dmem-mem1 -smp 2 \ > -numa node,nodeid=3D0 -numa node,nodeid=3D1 >=20 > To fix this issue, we've got to make sure to disable huge page support, > too, when there is a NUMA node that is not using a memory backend with > huge page support. >=20 > Fixes: 86b50f2e1befc33407bdfeb6f45f7b0d2439a740 > Signed-off-by: Thomas Huth > --- > target-ppc/kvm.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) >=20 > diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c > index 884d564..7a8f555 100644 > --- a/target-ppc/kvm.c > +++ b/target-ppc/kvm.c > @@ -389,12 +389,16 @@ static long getrampagesize(void) > =20 > object_child_foreach(memdev_root, find_max_supported_pagesize, &hpsi= ze); > =20 > - if (hpsize =3D=3D LONG_MAX) { > + if (hpsize =3D=3D LONG_MAX || hpsize =3D=3D getpagesize()) { > return getpagesize(); > } > =20 > - if (nb_numa_nodes =3D=3D 0 && hpsize > getpagesize()) { > - /* No NUMA nodes and normal RAM without -mem-path =3D=3D> no hug= e pages! */ > + /* If NUMA is disabled or the NUMA nodes are not backed with a > + * memory-backend, then there is at least one node using "normal" > + * RAM. And since normal RAM has not been configured with "-mem-path" > + * (what we've checked earlier here already), we can not use huge pa= ges! > + */ > + if (nb_numa_nodes =3D=3D 0 || numa_info[0].node_memdev =3D=3D NULL) { Is that second clause sufficient, or do you need to loop through and check the memdev of every node? > static bool warned; > if (!warned) { > error_report("Huge page support disabled (n/a for main memor= y)."); --=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 --c1qHkdEbEbCG94PZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXiKBSAAoJEGw4ysog2bOSQggP/1N2puUuHK0AWGvqMJfPH6FU I3ljpDr+AzLLRljuRJOeur1LI6reoBpzy9qVmYB+Rz1twulmyii+544q5/LwgV54 rS85MzgigO/RhkGWjrfr4FinDkRFhJx05xinp9W3XLXO9Ng9gwP9AKWFL+4jMNpH svh2Vfwcrn2L6+BTFI9MO7JvGHlkuPzl2roaOqHTk5cbWsHZvrNH12aqBob5yc1S 1UF/kj0+uCLVAhQCtVtkFjcWZShYex2oFL0ShomL4lwHDulOJT7/Yuba3ToX/UKM YkDjPfDYnA5+/lA2HpnId3ULv7HHHPKIJrfVFrjPYtalEbgfwGs7MUtS/Zibl0dX KqcDX+K58xDyFc+VoegEFcLldNu+96NzNOooZnCIy1EoAQrsgXbWr9/0mL72MRY6 8zbRKSREpuXF2O2wS4GG7Y6EQDn+Fm9MrcxdWlSu+jtvePzuz+fvJxvM7dHRuWgu nHw9Oios3Th5XqekEG5A/LQSiC96qGtskfqrLu++kDqcm/+xAZKxVnDIBHd20yuT Q7KXS2CKCI5tJDNNDTEN85zA6r9D+oXs+uILwv2a/O00TzDa+IHg/OgykD7uiueQ xTZEJifGBP7U6aD+aGvr65WezhNVnaKb19w5mbWlG1LjBRtN56S2U01WwH9Fgy7m 4xWnWeHmFBXF6udPmpfW =5WAj -----END PGP SIGNATURE----- --c1qHkdEbEbCG94PZ--