Re: [PATCH 3/7] RISC-V: Rework kernel's virtual address space mapping

2019-03-28 Thread Logan Gunthorpe



On 2019-03-28 12:28 a.m., Anup Patel wrote:
>>> 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...
> 
> That was a patch I submitted to fix overlapping FIXMAP and VMALLOC
> regions.
> 
> This patch does not consider FIXMAP region.

Correct.

> I suggest we introduce asm/memory.h where we have all critical defines
> related to virtual memory layout. Also, this header should have detailed
> comments about virtual memory layout.

Seems like a sensible cleanup. It did seem like the defines for this
stuff were all over the place. I'm not really clear on all the stuff
that would belong in asm/memory.h so I think I'll leave such a cleanup
to you.

The second patch in this series added documentation to describe the
virtual memory layout which matches how it was done in x86.

Logan


Re: [PATCH 3/7] RISC-V: Rework kernel's virtual address space mapping

2019-03-28 Thread Anup Patel
On Thu, Mar 28, 2019 at 11:09 AM Palmer Dabbelt  wrote:
>
> On Wed, 27 Mar 2019 14:36:39 PDT (-0700), log...@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:
> >
> >  - 7fff   user space, different per mm (2G)
> > 8000 - 81ff   virtual memory map (32MB)
> > 8200 - bfff   vmalloc/ioremap space (1GB - 32MB)
> > c000 -    direct mapping of all phys. memory (1GB)
> >
> > 64-bit, Sv39:
> >
> >  - 003f  user space, different per mm (256GB)
> > hole caused by [38:63] sign extension
> > ffc0 - ffc0  virtual memory map (4GB)
> > ffc1 - ffd0  vmalloc/ioremap spac (64GB)
> > ffd1 -   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...

That was a patch I submitted to fix overlapping FIXMAP and VMALLOC
regions.

This patch does not consider FIXMAP region.

I suggest we introduce asm/memory.h where we have all critical defines
related to virtual memory layout. Also, this header should have detailed
comments about virtual memory layout.

>
> > 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 0xC000 if 32BIT && MAXPHYSMEM_2GB
> >   default 0x8000 if 64BIT && MAXPHYSMEM_2GB
> > - default 0xffe0 if 64BIT && MAXPHYSMEM_128GB
> > + default 0xffd2 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 \
> > - 

Re: [PATCH 3/7] RISC-V: Rework kernel's virtual address space mapping

2019-03-27 Thread Palmer Dabbelt

On Wed, 27 Mar 2019 14:36:39 PDT (-0700), log...@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:

 - 7fff   user space, different per mm (2G)
8000 - 81ff   virtual memory map (32MB)
8200 - bfff   vmalloc/ioremap space (1GB - 32MB)
c000 -    direct mapping of all phys. memory (1GB)

64-bit, Sv39:

 - 003f  user space, different per mm (256GB)
hole caused by [38:63] sign extension
ffc0 - ffc0  virtual memory map (4GB)
ffc1 - ffd0  vmalloc/ioremap spac (64GB)
ffd1 -   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 0xC000 if 32BIT && MAXPHYSMEM_2GB
default 0x8000 if 64BIT && MAXPHYSMEM_2GB
-   default 0xffe0 if 64BIT && MAXPHYSMEM_128GB
+   default 0xffd2 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_ENDKERN_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)