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

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

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

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

2019-03-27 Thread Logan Gunthorpe
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