lkml.org 
[lkml]   [2020]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone
    From
    Date
    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

    \
     
     \ /
      Last update: 2020-07-23 07:22    [W:2.307 / U:0.708 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site