Messages in this thread | | | Subject | Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone | From | Alex Ghiti <> | Date | Thu, 23 Jul 2020 01:21:50 -0400 |
| |
Hi Benjamin,
Le 7/21/20 à 7:11 PM, Benjamin Herrenschmidt a écrit : > On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote: >>>> I guess I don't understand why this is necessary at all. >>>> Specifically: why >>>> can't we just relocate the kernel within the linear map? That would >>>> let the >>>> bootloader put the kernel wherever it wants, modulo the physical >>>> memory size we >>>> support. We'd need to handle the regions that are coupled to the >>>> kernel's >>>> execution address, but we could just put them in an explicit memory >>>> region >>>> which is what we should probably be doing anyway. >>> >>> Virtual relocation in the linear mapping requires to move the kernel >>> physically too. Zong implemented this physical move in its KASLR RFC >>> patchset, which is cumbersome since finding an available physical spot >>> is harder than just selecting a virtual range in the vmalloc range. >>> >>> In addition, having the kernel mapping in the linear mapping prevents >>> the use of hugepage for the linear mapping resulting in performance loss >>> (at least for the GB that encompasses the kernel). >>> >>> Why do you find this "ugly" ? The vmalloc region is just a bunch of >>> available virtual addresses to whatever purpose we want, and as noted by >>> Zong, arm64 uses the same scheme. > > I don't get it :-) > > At least on powerpc we move the kernel in the linear mapping and it > works fine with huge pages, what is your problem there ? You rely on > punching small-page size holes in there ? >
ARCH_HAS_STRICT_KERNEL_RWX prevents the use of a hugepage for the kernel mapping in the direct mapping as it sets different permissions to different part of the kernel (data, text..etc).
> At least in the old days, there were a number of assumptions that > the kernel text/data/bss resides in the linear mapping. > > If you change that you need to ensure that it's still physically > contiguous and you'll have to tweak __va and __pa, which might induce > extra overhead. >
Yes that's done in this patch and indeed there is an overhead to those functions.
> Cheers, > Ben. > >
Thanks,
Alex
| |