From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Matt Fleming <mfleming@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
Mario Limonciello <mario_limonciello@dell.com>,
Kees Cook <keescook@chromium.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>, X86 ML <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] x86/boot: Reorganize and clean up the BIOS area reservation code
Date: Thu, 21 Jul 2016 18:18:07 +0200 [thread overview]
Message-ID: <20160721161807.GB30106@gmail.com> (raw)
In-Reply-To: <CALCETrWmCrxyYcG308NBDzp1OMX6kG7PyVbpx3NDsuJCPW7D8A@mail.gmail.com>
* Andy Lutomirski <luto@amacapital.net> wrote:
> It would be very easy to implement this if we could handle overlapping memblocks
> precisely or set a lower limit on the memblock allocator. Then we could block
> off everything below 1MB or 2MB very early and then unblock it or temporarily
> change the lower limit and ask for a single page for the trampoline after that.
So my suggestion was/is to _permanently_ allocate the SMP trampoline page, and
leave it also reserved.
'Reserving' a memory area is really just a kernel internal matter. We can still
use it. No need to unreserve/allocate/re-reserve ... unless I'm missing something.
Thanks,
Ingo
next prev parent reply other threads:[~2016-07-21 16:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-21 1:32 [PATCH] x86/ebda: If the EBDA is in lowmem, reserve only 4k for the EBDA Andy Lutomirski
2016-07-21 8:14 ` [PATCH] x86/boot: Reorganize and clean up the BIOS area reservation code Ingo Molnar
2016-07-21 8:29 ` H. Peter Anvin
2016-07-21 9:11 ` Ingo Molnar
2016-07-21 12:32 ` H. Peter Anvin
2016-07-21 9:14 ` Ingo Molnar
2016-07-21 8:31 ` Ingo Molnar
2016-07-21 14:58 ` Andy Lutomirski
2016-07-21 16:18 ` Ingo Molnar [this message]
2016-07-21 21:08 ` Andy Lutomirski
2016-07-21 21:28 ` H. Peter Anvin
2016-07-21 21:48 ` Andy Lutomirski
2016-07-21 22:45 ` Andy Lutomirski
2016-07-22 13:00 ` Matt Fleming
2016-07-23 1:16 ` Linus Torvalds
2016-07-26 0:41 ` Andy Lutomirski
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=20160721161807.GB30106@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mario_limonciello@dell.com \
--cc=mfleming@suse.de \
--cc=mjg59@srcf.ucam.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@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.