From owner-svn-src-all@freebsd.org Mon May 14 04:00:53 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5721AFC3472; Mon, 14 May 2018 04:00:53 +0000 (UTC) (envelope-from nwhitehorn@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 092E885E7C; Mon, 14 May 2018 04:00:53 +0000 (UTC) (envelope-from nwhitehorn@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id DE68F16F23; Mon, 14 May 2018 04:00:52 +0000 (UTC) (envelope-from nwhitehorn@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w4E40qXK037421; Mon, 14 May 2018 04:00:52 GMT (envelope-from nwhitehorn@FreeBSD.org) Received: (from nwhitehorn@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w4E40qHr037419; Mon, 14 May 2018 04:00:52 GMT (envelope-from nwhitehorn@FreeBSD.org) Message-Id: <201805140400.w4E40qHr037419@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: nwhitehorn set sender to nwhitehorn@FreeBSD.org using -f From: Nathan Whitehorn Date: Mon, 14 May 2018 04:00:52 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r333599 - head/sys/powerpc/aim X-SVN-Group: head X-SVN-Commit-Author: nwhitehorn X-SVN-Commit-Paths: head/sys/powerpc/aim X-SVN-Commit-Revision: 333599 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 04:00:53 -0000 Author: nwhitehorn Date: Mon May 14 04:00:52 2018 New Revision: 333599 URL: https://svnweb.freebsd.org/changeset/base/333599 Log: Final fix for alignment issues with the page table first patched with r333273 and partially reverted with r333594. Older CPUs implement addition of offsets into the page table by a bitwise OR rather than actual addition, which only works if the table is aligned at a multiple of its own size (they also require it to be aligned at a multiple of 256KB). Newer ones do not have that requirement, but it hardly matters to enforce it anyway. The original code was failing on newer systems with huge amounts of RAM (> 512 GB), in which the page table was 4 GB in size. Because the bootstrap memory allocator took its alignment parameter as an int, this turned into a 0, removing any alignment constraint at all and making the MMU fail. The first round of this patch (r333273) fixed this case by aligning it at 256 KB, which broke older CPUs. Fix this instead by widening the alignment parameter. Modified: head/sys/powerpc/aim/mmu_oea64.c head/sys/powerpc/aim/mmu_oea64.h head/sys/powerpc/aim/moea64_native.c Modified: head/sys/powerpc/aim/mmu_oea64.c ============================================================================== --- head/sys/powerpc/aim/mmu_oea64.c Mon May 14 01:08:47 2018 (r333598) +++ head/sys/powerpc/aim/mmu_oea64.c Mon May 14 04:00:52 2018 (r333599) @@ -2446,7 +2446,7 @@ moea64_remove_all(mmu_t mmu, vm_page_t m) * calculated. */ vm_offset_t -moea64_bootstrap_alloc(vm_size_t size, u_int align) +moea64_bootstrap_alloc(vm_size_t size, vm_size_t align) { vm_offset_t s, e; int i, j; Modified: head/sys/powerpc/aim/mmu_oea64.h ============================================================================== --- head/sys/powerpc/aim/mmu_oea64.h Mon May 14 01:08:47 2018 (r333598) +++ head/sys/powerpc/aim/mmu_oea64.h Mon May 14 04:00:52 2018 (r333599) @@ -39,7 +39,7 @@ extern mmu_def_t oea64_mmu; */ /* Allocate physical memory for use in moea64_bootstrap. */ -vm_offset_t moea64_bootstrap_alloc(vm_size_t, u_int); +vm_offset_t moea64_bootstrap_alloc(vm_size_t size, vm_size_t align); /* Set an LPTE structure to match the contents of a PVO */ void moea64_pte_from_pvo(const struct pvo_entry *pvo, struct lpte *lpte); Modified: head/sys/powerpc/aim/moea64_native.c ============================================================================== --- head/sys/powerpc/aim/moea64_native.c Mon May 14 01:08:47 2018 (r333598) +++ head/sys/powerpc/aim/moea64_native.c Mon May 14 04:00:52 2018 (r333599) @@ -453,10 +453,11 @@ moea64_bootstrap_native(mmu_t mmup, vm_offset_t kernel } /* * PTEG table must be aligned on a 256k boundary, but can be placed - * anywhere with that alignment. Some of our hash calculations, - * however, assume that the PTEG table is aligned to its own size - * (low-order bits are zero in an OR). As such, make alignment - * bigger than strictly necessary for the time being. + * anywhere with that alignment on POWER ISA 3+ systems. On earlier + * systems, offset addition is done by the CPU with bitwise OR rather + * than addition, so the table must also be aligned on a boundary of + * its own size. Pick the larger of the two, which works on all + * systems. */ moea64_pteg_table = (struct lpte *)moea64_bootstrap_alloc(size, MAX(256*1024, size));