From: "tip-bot2 for Borislav Petkov" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Borislav Petkov <bp@suse.de>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: x86/cleanups] x86/setup: Document that Windows reserves the first MiB
Date: Tue, 08 Jun 2021 20:35:51 -0000 [thread overview]
Message-ID: <162318455123.29796.8536472725477120608.tip-bot2@tip-bot2> (raw)
In-Reply-To: =?utf-8?q?=3CMWHPR21MB159330952629D36EEDE706B3D7379=40MWHPR21MB?= =?utf-8?q?1593=2Enamprd21=2Eprod=2Eoutlook=2Ecom=3E?=
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: ec35d1d93bf8976f0668cb1026ea8c7d7bcad3c1
Gitweb: https://git.kernel.org/tip/ec35d1d93bf8976f0668cb1026ea8c7d7bcad3c1
Author: Borislav Petkov <bp@suse.de>
AuthorDate: Tue, 08 Jun 2021 22:17:10 +02:00
Committer: Borislav Petkov <bp@suse.de>
CommitterDate: Tue, 08 Jun 2021 22:26:43 +02:00
x86/setup: Document that Windows reserves the first MiB
It does so unconditionally too, on Intel and AMD machines, to work
around BIOS bugs, as confirmed by Microsoft folks (see Link for full
details).
Reflow the paragraph, while at it.
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/MWHPR21MB159330952629D36EEDE706B3D7379@MWHPR21MB1593.namprd21.prod.outlook.com
---
arch/x86/kernel/setup.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 7638ac6..85acd22 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1060,17 +1060,18 @@ void __init setup_arch(char **cmdline_p)
#endif
/*
- * Find free memory for the real mode trampoline and place it
- * there.
- * If there is not enough free memory under 1M, on EFI-enabled
- * systems there will be additional attempt to reclaim the memory
- * for the real mode trampoline at efi_free_boot_services().
+ * Find free memory for the real mode trampoline and place it there. If
+ * there is not enough free memory under 1M, on EFI-enabled systems
+ * there will be additional attempt to reclaim the memory for the real
+ * mode trampoline at efi_free_boot_services().
*
- * Unconditionally reserve the entire first 1M of RAM because
- * BIOSes are know to corrupt low memory and several
- * hundred kilobytes are not worth complex detection what memory gets
- * clobbered. Moreover, on machines with SandyBridge graphics or in
- * setups that use crashkernel the entire 1M is reserved anyway.
+ * Unconditionally reserve the entire first 1M of RAM because BIOSes
+ * are known to corrupt low memory and several hundred kilobytes are not
+ * worth complex detection what memory gets clobbered. Windows does the
+ * same thing for very similar reasons.
+ *
+ * Moreover, on machines with SandyBridge graphics or in setups that use
+ * crashkernel the entire 1M is reserved anyway.
*/
reserve_real_mode();
reply other threads:[~2021-06-08 20:35 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=162318455123.29796.8536472725477120608.tip-bot2@tip-bot2 \
--to=tip-bot2@linutronix.de \
--cc=bp@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).