From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Yinghai Lu <yinghai@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@elte.hu>,
the arch/x86 maintainers <x86@kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] x86: add brk allocator for very early allocations
Date: Fri, 13 Mar 2009 13:27:28 -0700 [thread overview]
Message-ID: <49BAC1B0.6050107@goop.org> (raw)
In-Reply-To: <49B9AC7F.9030302@kernel.org>
Yinghai Lu wrote:
> Jeremy Fitzhardinge wrote:
>
>> Yinghai Lu wrote:
>>
>>> could have more explanation about the 1M size.
>>> because initial_pg_tables will sit in it. please consider to add
>>> something like
>>>
>>> in head_32.S
>>>
>>> LOW_PAGES = (KERNEL_IMAGE_SIZE + PAGE_SIZE_asm - 1)>>PAGE_SHIFT
>>>
>>> #if PTRS_PER_PMD > 1
>>> PAGE_TABLE_SIZE = (LOW_PAGES / PTRS_PER_PMD) + PTRS_PER_PGD
>>> #else
>>> PAGE_TABLE_SIZE = (LOW_PAGES / PTRS_PER_PGD)
>>> #endif
>>> ALLOCATOR_SLOP = 4
>>>
>>>
>> OK, how does this look:
>>
>> The following changes since commit
>> 21e8ba72daf5d7f0af33968f873499c85f96ccef:
>> Jeremy Fitzhardinge (1):
>> x86: use brk allocation for DMI
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git push/x86/brk
>>
>> Jeremy Fitzhardinge (1):
>> x86: allow extend_brk users to reserve brk space
>>
>> Yinghai Lu (1):
>> x86-32: compute initial mapping size more accurately
>>
>> arch/x86/include/asm/page_32_types.h | 5 +++++
>> arch/x86/include/asm/setup.h | 30 ++++++++++++++++++++++++++++++
>> arch/x86/kernel/head_32.S | 4 +++-
>> arch/x86/kernel/setup.c | 2 ++
>> arch/x86/kernel/vmlinux_32.lds.S | 4 +++-
>> arch/x86/kernel/vmlinux_64.lds.S | 4 +++-
>> 6 files changed, 46 insertions(+), 3 deletions(-)
>>
>> git diff 21e8ba72daf5d7f0af33968f873499c85f96ccef..push/x86/brk
>> diff --git a/arch/x86/include/asm/page_32_types.h
>> b/arch/x86/include/asm/page_32_types.h
>> index f1e4a79..0f915ae 100644
>> --- a/arch/x86/include/asm/page_32_types.h
>> +++ b/arch/x86/include/asm/page_32_types.h
>> @@ -39,6 +39,11 @@
>> #define __VIRTUAL_MASK_SHIFT 32
>> #endif /* CONFIG_X86_PAE */
>>
>> +/*
>> + * Kernel image size is limited to 512 MB (see in
>> arch/x86/kernel/head_32.S)
>> + */
>> +#define KERNEL_IMAGE_SIZE (512 * 1024 * 1024)
>> +
>> #ifndef __ASSEMBLY__
>>
>> /*
>> diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
>> index 366d366..61b126b 100644
>> --- a/arch/x86/include/asm/setup.h
>> +++ b/arch/x86/include/asm/setup.h
>> @@ -104,6 +104,29 @@ extern struct boot_params boot_params;
>> extern unsigned long _brk_end;
>> void *extend_brk(size_t size, size_t align);
>>
>> +/*
>> + * Reserve space in the brk section. The name must be unique within
>> + * the file, and somewhat descriptive. The size is in bytes. Must be
>> + * used at file scope.
>> + *
>> + * (This uses a temp function to wrap the asm so we can pass it the
>> + * size parameter; otherwise we wouldn't be able to. We can't use a
>> + * "section" attribute on a normal variable because it always ends up
>> + * being @progbits, which ends up allocating space in the vmlinux
>> + * executable.)
>> + */
>> +#define RESERVE_BRK(name,sz) \
>> + static void __section(.discard) __used \
>> + __brk_reservation_fn_##name##__(void) { \
>> + asm volatile ( \
>> + ".pushsection .brk_reservation,\"aw\",@nobits;" \
>> + "__brk_reservation_" #name "__:" \
>> + " 1:.skip %c0;" \
>> + " .size __brk_reservation_" #name "__, . - 1b;" \
>> + " .popsection" \
>> + : : "i" (sz)); \
>> + }
>> +
>> #ifdef __i386__
>>
>> void __init i386_start_kernel(void);
>> @@ -115,6 +138,13 @@ void __init x86_64_start_reservations(char
>> *real_mode_data);
>>
>> #endif /* __i386__ */
>> #endif /* _SETUP */
>> +#else
>> +#define RESERVE_BRK(name,sz) \
>> + .pushsection .brk_reservation,"aw",@nobits; \
>> +__brk_reservation_##name##__: \
>> +1: .skip sz; \
>> + .size __brk_reservation_##name##__,.-1b; \
>> + .popsection
>> #endif /* __ASSEMBLY__ */
>> #endif /* __KERNEL__ */
>>
>> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
>> index d243437..80dc05e 100644
>> --- a/arch/x86/kernel/head_32.S
>> +++ b/arch/x86/kernel/head_32.S
>> @@ -54,7 +54,7 @@
>> *
>> * This should be a multiple of a page.
>> */
>> -LOW_PAGES = 1<<(32-PAGE_SHIFT_asm)
>> +LOW_PAGES = (KERNEL_IMAGE_SIZE + PAGE_SIZE_asm - 1)>>PAGE_SHIFT
>>
>> /*
>> * To preserve the DMA pool in PAGEALLOC kernels, we'll allocate
>> @@ -75,6 +75,8 @@ ALLOCATOR_SLOP = 4
>>
>> INIT_MAP_BEYOND_END = BOOTBITMAP_SIZE + (PAGE_TABLE_SIZE +
>> ALLOCATOR_SLOP)*PAGE_SIZE_asm
>>
>
> no user for INIT_MAP_BEYOND_END any more.
>
There are several remaining references:
: abulafia:pts/0; grep INIT_MAP_BEYOND_END arch/x86/kernel/head_32.S
INIT_MAP_BEYOND_END = BOOTBITMAP_SIZE + (PAGE_TABLE_SIZE + ALLOCATOR_SLOP)*PAGE_SIZE_asm
* and PAGE_OFFSET for up to _end+sizeof(page tables)+INIT_MAP_BEYOND_END.
* End condition: we must map up to and including INIT_MAP_BEYOND_END
leal (INIT_MAP_BEYOND_END+PTE_IDENT_ATTR)(%edi),%ebp
* End condition: we must map up to and including INIT_MAP_BEYOND_END
leal (INIT_MAP_BEYOND_END+PTE_IDENT_ATTR)(%edi),%ebp
Are you saying they're redundant and should be removed?
> could add
> /*
> * Build-time check on the image size:
> */
> ASSERT((_end - LOAD_OFFSET <= KERNEL_IMAGE_SIZE),
> "kernel image bigger than KERNEL_IMAGE_SIZE")
>
>
> for 32bit
>
I guess we could, but it doesn't seem very urgent.
J
next prev parent reply other threads:[~2009-03-13 20:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-11 16:59 [GIT PULL] x86: add brk allocator for very early allocations Jeremy Fitzhardinge
2009-03-11 18:19 ` Yinghai Lu
2009-03-12 23:59 ` Jeremy Fitzhardinge
2009-03-13 0:44 ` Yinghai Lu
2009-03-13 20:27 ` Jeremy Fitzhardinge [this message]
2009-03-13 21:03 ` Yinghai Lu
2009-03-13 22:45 ` H. Peter Anvin
2009-03-13 22:59 ` Jeremy Fitzhardinge
2009-03-13 23:20 ` Yinghai Lu
2009-03-14 0:23 ` Jeremy Fitzhardinge
2009-03-11 19:20 ` Eric W. Biederman
2009-03-11 23:53 ` Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49BAC1B0.6050107@goop.org \
--to=jeremy@goop.org \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.