Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp269045img; Wed, 27 Mar 2019 22:40:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqxzG4J2eO4bJ/qiHiWWRk3mfRLGIUqGLoJcKnPcvbWr+8AUZv8AfimXzXumk9o9iOgK8NT+ X-Received: by 2002:a63:ff1d:: with SMTP id k29mr38883369pgi.258.1553751629929; Wed, 27 Mar 2019 22:40:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553751629; cv=none; d=google.com; s=arc-20160816; b=FwFESWWFbiWbKzuOR7Te391C4wol88U9KxTd52FD0fjlZ311ttbK9mCjdM38mW3G6c +49gqnMHOv162VLx1O70WKSgfGT1Udn9jcnGR62S789xY8RsTd1y032JMo4djtuDK5cA 0E1fUD9hppuNydxQRL6YlPf+4LtFrHaRnoGRdb/FrRbx/LSK7igfr+LACUlAEARaC2m6 vfJ+aFxzut9ds6CORyjFNuzoIRtSff91zcV4SWpx58t5NSlFU9thc0ktfGcnYdNP16vz ZpxC9iHWg55KIBWjfUqXLtrmkcYCX8ooTo+iYQR4I7PRBzXqQpUlfpCg1YNLjBAFrRof Dpfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:to:from:cc:in-reply-to:subject:date:dkim-signature; bh=FVTIAp+AHigUlUaGp3ARcNFkfdWonWsh7STo70xb6HE=; b=0AzGFEWEs2j7oYoCN2BwHYeIeKIn+cK9mriTx787d0lJlL60OCZiGNL+nh8aB1W1pG QNY/8sizvulYLRMsrDUhEPZUWNjeFU+CPyrnAn/K/RTkuxIG1phnRAJkJo8oM4CE9RjT dxPJAJ7Ze33aART9pklCxsAMYdf6/Za8pKIZj6kFRyBl5dV3qtM4ryPccUWUWqM+qZFx Btxc2fQFd9bpG+43qr7lKzsBkJLbcd972n0rB7VlludDRymjOwKkVhUnYZejHTQ8lc4B 4kBFJ+05d2FongxfBJzdz/UbX9c1ijNVl4U+EIly3cO4udZtiyPVZKelfgsVOiYLfS3z W4yQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=iC0nRwdY; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w67si4650613pfb.20.2019.03.27.22.40.13; Wed, 27 Mar 2019 22:40:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@sifive.com header.s=google header.b=iC0nRwdY; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726045AbfC1Fjh (ORCPT + 99 others); Thu, 28 Mar 2019 01:39:37 -0400 Received: from mail-pf1-f195.google.com ([209.85.210.195]:42927 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725806AbfC1Fjg (ORCPT ); Thu, 28 Mar 2019 01:39:36 -0400 Received: by mail-pf1-f195.google.com with SMTP id r15so10808123pfn.9 for ; Wed, 27 Mar 2019 22:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=FVTIAp+AHigUlUaGp3ARcNFkfdWonWsh7STo70xb6HE=; b=iC0nRwdY2t02geyoPPs/ajI2+Nk5eq/9ZMIwzN0+7I3b3VUr/7mkhTG25WiaYS0S49 cmhfN5W2v5DxP9c87WWQe6u72aJoANBU0aqWqlK6UR9wXk9Evnwfi554G6SAJBkbQDKS Wj+L2/wEp2NIf+zkPkuRaRYBe3KEvyyAYsHP1/ifQQp5OqUF1wmcujLmtbCmquFVE8QV P6Y2ExtJuUtFZN4JOKq5abWJa+PUUU+/3rx7GR6cvN1NINJvN8YHkYI2fqqBlaT1ZeiO 0XRT4N86/vrhbKGz6QkmpXI/mhdi5DrRQK5JPyMWr0PD0w+JjoQoX/lhwm6vBFTbI+mA icAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=FVTIAp+AHigUlUaGp3ARcNFkfdWonWsh7STo70xb6HE=; b=fyjmHfKPi4MKZ6Ny7XnCYtUhYuX0CKBd0M4gFI95fhi4F8c1jTFRxkVjJryjpyseNk 9VzmyVNOV/6qRsF+wDr99v1QjuCqja4AxtOxPf08L4T5vzdwtoAv6cVBNB1NheMqMmwz IA2enNWPwfNPbZu0OlSqaRDzFcAsG2SxJxKKd4alLiegZfE0yeaYxCIOEPlwRgPYby+s N2IC6qChgpob8OKzk1rciKQ2hUYPpMaLxCIU7hTWJCGdG84WLRMKm+cgqzxTyI8MszwR hAcgDTWSN61G5wJtJCABimqL5tqf8hGrCt4o5DekYSBCH2XsfaA2dD+8iQICuyGrnOyl fCCg== X-Gm-Message-State: APjAAAVv5LCIhGYP7Z+27dyJFxnq/zs2hLlSpBXka9P5GNJ26tDkyN/t M1ZYOrJ21mxl1aHTz0y6Q0vmICuMP59D95XI X-Received: by 2002:a63:4750:: with SMTP id w16mr38983883pgk.256.1553751575232; Wed, 27 Mar 2019 22:39:35 -0700 (PDT) Received: from localhost (2001-b011-7001-168c-9355-f21f-1416-8b19.dynamic-ip6.hinet.net. [2001:b011:7001:168c:9355:f21f:1416:8b19]) by smtp.gmail.com with ESMTPSA id u10sm26809103pgr.2.2019.03.27.22.39.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 22:39:33 -0700 (PDT) Date: Wed, 27 Mar 2019 22:39:33 -0700 (PDT) X-Google-Original-Date: Wed, 27 Mar 2019 21:04:20 PDT (-0700) Subject: Re: [PATCH 3/7] RISC-V: Rework kernel's virtual address space mapping In-Reply-To: <20190327213643.23789-4-logang@deltatee.com> CC: linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, sbates@raithlin.com, Christoph Hellwig , aou@eecs.berkeley.edu, logang@deltatee.com, antonynpavlov@gmail.com, sorear2@gmail.com, anup.patel@wdc.com From: Palmer Dabbelt To: logang@deltatee.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 27 Mar 2019 14:36:39 PDT (-0700), logang@deltatee.com wrote: > The motivation for this is to support P2P transactions. P2P requires > having struct pages for IO memory which means the linear mapping must > be able to cover all of the IO regions. Unfortunately with Sv39 we are > not able to cover all the IO regions available on existing hardware, > but we can do better than what we currently do (which only cover's > physical memory). > > To this end, we restructure the kernel's virtual address space region. > We position the vmemmap at the beginning of the region (based on how > many virtual address bits we have) and the VMALLOC region comes > immediately after. The linear mapping then takes up the remaining space. > PAGE_OFFSET will need to be within the linear mapping but may not be > the start of the mapping seeing many machines don't have RAM at address > zero and we may still want to access lower addresses through the > linear mapping. > > With these changes, on a 64-bit system the virtual memory map (with > sparsemem enabled) will be: > > 32-bit: > > 00000000 - 7fffffff user space, different per mm (2G) > 80000000 - 81ffffff virtual memory map (32MB) > 82000000 - bfffffff vmalloc/ioremap space (1GB - 32MB) > c0000000 - ffffffff direct mapping of all phys. memory (1GB) > > 64-bit, Sv39: > > 0000000000000000 - 0000003fffffffff user space, different per mm (256GB) > hole caused by [38:63] sign extension > ffffffc000000000 - ffffffc0ffffffff virtual memory map (4GB) > ffffffc100000000 - ffffffd0ffffffff vmalloc/ioremap spac (64GB) > ffffffd100000000 - ffffffffffffffff linear mapping of phys. space (188GB) > > On the Sifive hardware this allows us to provide struct pages for > the lower I/O TileLink address ranges, the 32-bit and 34-bit DRAM areas > and 172GB of 240GB of the high I/O TileLink region. Once we progress to > Sv48 we should be able to cover all the available memory regions.. > > For the MAXPHYSMEM_2GB case, the physical memory must be in the highest > 2GB of address space, so we cannot cover the any of the I/O regions > that are higher than it but we do cover the lower I/O TileLink range. IIRC there was another patch floating around to fix an issue with overlapping regions in the 32-bit port, did you also fix that issue? It's somewhere in my email queue... > Signed-off-by: Logan Gunthorpe > Cc: Palmer Dabbelt > Cc: Albert Ou > Cc: Antony Pavlov > Cc: "Stefan O'Rear" > Cc: Anup Patel > --- > arch/riscv/Kconfig | 2 +- > arch/riscv/include/asm/page.h | 2 -- > arch/riscv/include/asm/pgtable.h | 27 ++++++++++++++++++--------- > 3 files changed, 19 insertions(+), 12 deletions(-) > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 76fc340ae38e..d21e6a12e8b6 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -71,7 +71,7 @@ config PAGE_OFFSET > hex > default 0xC0000000 if 32BIT && MAXPHYSMEM_2GB > default 0xffffffff80000000 if 64BIT && MAXPHYSMEM_2GB > - default 0xffffffe000000000 if 64BIT && MAXPHYSMEM_128GB > + default 0xffffffd200000000 if 64BIT && MAXPHYSMEM_128GB > > config ARCH_FLATMEM_ENABLE > def_bool y > diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h > index 2a546a52f02a..fa0b8058a246 100644 > --- a/arch/riscv/include/asm/page.h > +++ b/arch/riscv/include/asm/page.h > @@ -31,8 +31,6 @@ > */ > #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL) > > -#define KERN_VIRT_SIZE (-PAGE_OFFSET) > - > #ifndef __ASSEMBLY__ > > #define PAGE_UP(addr) (((addr)+((PAGE_SIZE)-1))&(~((PAGE_SIZE)-1))) > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index 5a9fea00ba09..2a5070540996 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -89,22 +89,31 @@ extern pgd_t swapper_pg_dir[]; > #define __S110 PAGE_SHARED_EXEC > #define __S111 PAGE_SHARED_EXEC > > -#define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1) > -#define VMALLOC_END (PAGE_OFFSET - 1) > -#define VMALLOC_START (PAGE_OFFSET - VMALLOC_SIZE) > +#define KERN_SPACE_START (-1UL << (CONFIG_VA_BITS - 1)) > > /* > * Roughly size the vmemmap space to be large enough to fit enough > * struct pages to map half the virtual address space. Then > * position vmemmap directly below the VMALLOC region. > */ > -#define VMEMMAP_SHIFT \ > - (CONFIG_VA_BITS - PAGE_SHIFT - 1 + STRUCT_PAGE_MAX_SHIFT) > -#define VMEMMAP_SIZE (1UL << VMEMMAP_SHIFT) > -#define VMEMMAP_END (VMALLOC_START - 1) > -#define VMEMMAP_START (VMALLOC_START - VMEMMAP_SIZE) > - > +#ifdef CONFIG_SPARSEMEM > +#define VMEMMAP_SIZE (UL(1) << (CONFIG_VA_BITS - PAGE_SHIFT - 1 + \ > + STRUCT_PAGE_MAX_SHIFT)) > +#define VMEMMAP_START (KERN_SPACE_START) > +#define VMEMMAP_END (VMEMMAP_START + VMEMMAP_SIZE - 1) > #define vmemmap ((struct page *)VMEMMAP_START) > +#else > +#define VMEMMAP_END KERN_SPACE_START > +#endif > + > +#ifdef CONFIG_32BIT > +#define VMALLOC_SIZE ((1UL << 30) - VMEMMAP_SIZE) > +#else > +#define VMALLOC_SIZE (64UL << 30) > +#endif > + > +#define VMALLOC_START (VMEMMAP_END + 1) > +#define VMALLOC_END (VMALLOC_START + VMALLOC_SIZE - 1) > > /* > * ZERO_PAGE is a global shared page that is always zero,