Messages in this thread | | | Date | Wed, 15 Apr 2020 19:24:07 +0530 | From | afzal mohammed <> | Subject | Re: [PATCH 0/3] Highmem support for 32-bit RISC-V |
| |
Hi,
On Tue, Apr 14, 2020 at 09:29:46PM +0200, Arnd Bergmann wrote: > On Tue, Apr 14, 2020 at 5:17 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote:
> > + rmk
[ Forgot to provide context to Russell - this is about implementing VMSPLIT_4G_4G support for 32-bit ARM as a possible replacement of highmem ]
> > If no one have yet taken it up, i am interested in doing the work, i > > will sponsor myself :). i will proceed at a slow pace without derailing > > my other things normal.
> Thanks for offering to help, it's very much appreciated. Let me know how > it goes and if you have any more detailed questions.
Okay, i will proceed initially w/ things that can be done using qemu & available ARM boards. Right now no questions, i will probably be coming up with questions later.
Regards afzal
> I would recommend starting in a qemu emulated system on a PC host, > you can just set it to emulate a Cortex-A15 or A7, and you can attach > gdb to the qemu instance to see where it crashes (which it inevitably > will). > > You can also start by changing the functions in asm/uaccess.h to > use the linear kernel mapping and memcpy(), like the version in > arch/um/kernel/skas/uaccess.c does. This is slow, but will work on > regardless of whether user space is mapped, and you can do a > generic implementation that works on any architecture and put that > into include/asm-generic/uaccess.h. > > A second step after that could be to unmap user space when entering > the kernel, without any change in the memory layout, this is still > mostly hardware independent and could easily be done in qemu > or any 32-bit ARM CPU. > > Another thing to try early is to move the vmlinux virtual address > from the linear mapping into vmalloc space. This does not require > LPAE either, but it only works on relatively modern platforms that > don't have conflicting fixed mappings there. > > If you get that far, I'll happily buy you a Raspberry Pi 4 with 4GB > for further experiments ;-) > That one can run both 64-bit and 32-bit kernels (with LPAE), > so you'd be able to test the limits and not rely on qemu to find > all bugs such as missing TLB flushes or barriers.
| |