lkml.org 
[lkml]   [2016]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory
    On Wed, Dec 30, 2015 at 04:26:10PM +0100, Ard Biesheuvel wrote:
    > +static void __init enforce_memory_limit(void)
    > +{
    > + const phys_addr_t kbase = round_down(__pa(_text), MIN_KIMG_ALIGN);
    > + u64 to_remove = memblock_phys_mem_size() - memory_limit;
    > + phys_addr_t max_addr = 0;
    > + struct memblock_region *r;
    > +
    > + if (memory_limit == (phys_addr_t)ULLONG_MAX)
    > + return;
    > +
    > + /*
    > + * The kernel may be high up in physical memory, so try to apply the
    > + * limit below the kernel first, and only let the generic handling
    > + * take over if it turns out we haven't clipped enough memory yet.
    > + */
    > + for_each_memblock(memory, r) {
    > + if (r->base + r->size > kbase) {
    > + u64 rem = min(to_remove, kbase - r->base);
    > +
    > + max_addr = r->base + rem;
    > + to_remove -= rem;
    > + break;
    > + }
    > + if (to_remove <= r->size) {
    > + max_addr = r->base + to_remove;
    > + to_remove = 0;
    > + break;
    > + }
    > + to_remove -= r->size;
    > + }
    > +
    > + memblock_remove(0, max_addr);
    > +
    > + if (to_remove)
    > + memblock_enforce_memory_limit(memory_limit);
    > +}

    IIUC, this is changing the user expectations a bit. There are people
    using the mem= limit to hijack some top of the RAM for other needs
    (though they could do it in a saner way like changing the DT memory
    nodes). Your patch first tries to remove the memory below the kernel
    image and only remove the top if additional limitation is necessary.

    Can you not remove memory from the top and block the limit if it goes
    below the end of the kernel image, with some warning that memory limit
    was not entirely fulfilled?

    --
    Catalin

    \
     
     \ /
      Last update: 2016-01-08 17:21    [W:4.071 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site