grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: kern/efi/mm.c - MAX_USABLE_ADDRESS
Date: Mon, 09 Dec 2013 20:43:57 +0100	[thread overview]
Message-ID: <52A61D7D.60109@gmail.com> (raw)
In-Reply-To: <52A61537.7030407@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2957 bytes --]

On 09.12.2013 20:08, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 09.12.2013 18:30, Leif Lindholm wrote:
>> Hi,
>>
>> The EFI memory management code contains a hard-wired limit restricting
>> physical (and virtual, all 1:1 mapped in UEFI) addresses to 32-bit.
>> While this may be the right thing to do on x86, and hasn't caused me
>> any issues on 32-bit ARM, I have received reports of at least two
>> upcoming 64-bit ARM platforms with no RAM in the lower 4GB of physical
>> address space.
>>
>> A simple fix would be to just stack the ifdefs, but a better one might
>> be to move the define to one of <cpu/efi/memory.h> (which is currently
>> a dummy for all platforms, simply including <efi/memory.h>) or types.h.
>>
> cpu/efi/memory.h is a possibility. cpu/types.h isn't because it's, at
> least partially, EFI limitation (due to EFI bugs), not CPU. Real
> restrictions is a mix of unrelated restriction but it seem to align well
> with CPU.
> Increasing it beyond 0xffffffff will need chacking that efi/mm.c can
> handle it without overflow.
> The limits are:
> -0xffffffff on 32-bit platforms due to address space size (i386, arm)
> -0x7fffffff when x86_64 compiled without -mcmodel=large due to compiler
> assumptions
> -0xffffffff on x86_64 because some EFI implementations don't map memory
> above 4G contrary to spec.
> - On ia64 it's probably unlimited but I didn't test and there is always
> a danger of EFI bugs similar to x86_64 one, so better to be conservative
> about it
> - arm64. You're the expert.

If you want to increase it to 0xffffffffffffffff you'll need patch at
bottom of this mail. All other uses of MAX_USABLE_ADDRESS seem to be
fine. With this patch we would lose the last usable page but it's just
4K and this page is dangerous for overflows anyway so better to avoid.
I'd suggest using something lower (perhaps 1M lower) to avoid potential
bugs in EFI.

diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c
index 6e9dace..2becb7b 100644
--- a/grub-core/kern/efi/mm.c
+++ b/grub-core/kern/efi/mm.c
@@ -30,6 +30,7 @@
   ((grub_efi_memory_descriptor_t *) ((char *) (desc) + (size)))

 #define BYTES_TO_PAGES(bytes)  (((bytes) + 0xfff) >> 12)
+#define BYTES_TO_PAGES_DOWN(bytes)     ((bytes) >> 12)
 #define PAGES_TO_BYTES(pages)  ((pages) << 12)

 #if defined (__code_model_large__) || !defined (__x86_64__)
@@ -343,9 +344,9 @@ filter_memory_map (grub_efi_memory_descriptor_t
*memory_map,
 #if 1
          if (BYTES_TO_PAGES (filtered_desc->physical_start)
              + filtered_desc->num_pages
-             > BYTES_TO_PAGES (MAX_USABLE_ADDRESS+1LL))
+             > BYTES_TO_PAGES_DOWN (MAX_USABLE_ADDRESS))
            filtered_desc->num_pages
-             = (BYTES_TO_PAGES (MAX_USABLE_ADDRESS+1LL)
+             = (BYTES_TO_PAGES_DOWN (MAX_USABLE_ADDRESS)
                 - BYTES_TO_PAGES (filtered_desc->physical_start));
 #endif




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 291 bytes --]

  reply	other threads:[~2013-12-09 19:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-09 17:30 kern/efi/mm.c - MAX_USABLE_ADDRESS Leif Lindholm
2013-12-09 19:08 ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-09 19:43   ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2013-12-09 21:26     ` Leif Lindholm
2013-12-09 21:17   ` Leif Lindholm
2013-12-10 14:59     ` Leif Lindholm
2013-12-10 16:00       ` Vladimir 'φ-coder/phcoder' Serbinenko
2013-12-10 17:15         ` Leif Lindholm
2013-12-10 18:00           ` Vladimir 'φ-coder/phcoder' Serbinenko

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=52A61D7D.60109@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.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).