* kern/efi/mm.c - MAX_USABLE_ADDRESS @ 2013-12-09 17:30 Leif Lindholm 2013-12-09 19:08 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 1 reply; 9+ messages in thread From: Leif Lindholm @ 2013-12-09 17:30 UTC (permalink / raw) To: grub-devel 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. So, for something compile tested only on arm64: diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c index 6e9dace..5673d23 100644 --- a/grub-core/kern/efi/mm.c +++ b/grub-core/kern/efi/mm.c @@ -32,12 +32,6 @@ #define BYTES_TO_PAGES(bytes) (((bytes) + 0xfff) >> 12) #define PAGES_TO_BYTES(pages) ((pages) << 12) -#if defined (__code_model_large__) || !defined (__x86_64__) -#define MAX_USABLE_ADDRESS 0xffffffff -#else -#define MAX_USABLE_ADDRESS 0x7fffffff -#endif - /* The size of a memory map obtained from the firmware. This must be a multiplier of 4KB. */ #define MEMORY_MAP_SIZE 0x3000 diff --git a/include/grub/arm/types.h b/include/grub/arm/types.h index 4a806d0..612ea57 100644 --- a/include/grub/arm/types.h +++ b/include/grub/arm/types.h @@ -25,6 +25,8 @@ /* The size of long. */ #define GRUB_TARGET_SIZEOF_LONG 4 +#define MAX_USABLE_ADDRESS 0xffffffff + /* currently only support little-endian. */ #undef GRUB_TARGET_WORDS_BIGENDIAN diff --git a/include/grub/arm64/types.h b/include/grub/arm64/types.h index d132c5e..d52967d 100644 --- a/include/grub/arm64/types.h +++ b/include/grub/arm64/types.h @@ -25,6 +25,8 @@ /* The size of long. */ #define GRUB_TARGET_SIZEOF_LONG 8 +#define MAX_USABLE_ADDRESS 0xffffffffffffULL + /* currently only support little-endian. */ #undef GRUB_TARGET_WORDS_BIGENDIAN diff --git a/include/grub/i386/types.h b/include/grub/i386/types.h index c20063f..7fa7917 100644 --- a/include/grub/i386/types.h +++ b/include/grub/i386/types.h @@ -25,6 +25,12 @@ /* The size of long. */ #define GRUB_TARGET_SIZEOF_LONG 4 +#if defined (__code_model_large__) +#define MAX_USABLE_ADDRESS 0xffffffff +#else +#define MAX_USABLE_ADDRESS 0x7fffffff +#endif + /* i386 is little-endian. */ #undef GRUB_TARGET_WORDS_BIGENDIAN diff --git a/include/grub/ia64/types.h b/include/grub/ia64/types.h index 91a546d..8f13cf6 100644 --- a/include/grub/ia64/types.h +++ b/include/grub/ia64/types.h @@ -25,6 +25,8 @@ /* The size of long. */ #define GRUB_TARGET_SIZEOF_LONG 8 +#define MAX_USABLE_ADDRESS 0xffffffff + /* ia64 is little-endian (usually). */ #undef GRUB_TARGET_WORDS_BIGENDIAN diff --git a/include/grub/x86_64/types.h b/include/grub/x86_64/types.h index d53138e..baa31bb 100644 --- a/include/grub/x86_64/types.h +++ b/include/grub/x86_64/types.h @@ -25,6 +25,12 @@ /* The size of long. */ #define GRUB_TARGET_SIZEOF_LONG 8 +#if defined (__code_model_large__) +#define MAX_USABLE_ADDRESS 0xffffffff +#else +#define MAX_USABLE_ADDRESS 0x7fffffff +#endif + /* x86_64 is little-endian. */ #undef GRUB_TARGET_WORDS_BIGENDIAN --- Would a cleaned-up patch of the same be acceptable? / Leif ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: kern/efi/mm.c - MAX_USABLE_ADDRESS 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 2013-12-09 21:17 ` Leif Lindholm 0 siblings, 2 replies; 9+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-09 19:08 UTC (permalink / raw) To: The development of GNU GRUB [-- Attachment #1: Type: text/plain, Size: 1854 bytes --] 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. > --- a/include/grub/i386/types.h > +++ b/include/grub/i386/types.h > @@ -25,6 +25,12 @@ > /* The size of long. */ > #define GRUB_TARGET_SIZEOF_LONG 4 > > +#if defined (__code_model_large__) > +#define MAX_USABLE_ADDRESS 0xffffffff > +#else > +#define MAX_USABLE_ADDRESS 0x7fffffff > +#endif > + Should be MAX_USABLE_ADDRESS 0xffffffff [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kern/efi/mm.c - MAX_USABLE_ADDRESS 2013-12-09 19:08 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-09 19:43 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-09 21:26 ` Leif Lindholm 2013-12-09 21:17 ` Leif Lindholm 1 sibling, 1 reply; 9+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-09 19:43 UTC (permalink / raw) To: The development of GNU GRUB [-- 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 --] ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: kern/efi/mm.c - MAX_USABLE_ADDRESS 2013-12-09 19:43 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-09 21:26 ` Leif Lindholm 0 siblings, 0 replies; 9+ messages in thread From: Leif Lindholm @ 2013-12-09 21:26 UTC (permalink / raw) To: The development of GNU GRUB On Mon, Dec 09, 2013 at 08:43:57PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > 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. I can limit myself to 48 bits addressing due to current architectural restrictions, so not strictly speaking required, but... > 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. ...this certainly looks like a good idea regardless. > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kern/efi/mm.c - MAX_USABLE_ADDRESS 2013-12-09 19:08 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-09 19:43 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-09 21:17 ` Leif Lindholm 2013-12-10 14:59 ` Leif Lindholm 1 sibling, 1 reply; 9+ messages in thread From: Leif Lindholm @ 2013-12-09 21:17 UTC (permalink / raw) To: The development of GNU GRUB On Mon, Dec 09, 2013 at 08:08:39PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > > 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. Ah, ok - that makes sense then. > 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. Thank you - that makes it very clear. / Leif ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kern/efi/mm.c - MAX_USABLE_ADDRESS 2013-12-09 21:17 ` Leif Lindholm @ 2013-12-10 14:59 ` Leif Lindholm 2013-12-10 16:00 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 1 reply; 9+ messages in thread From: Leif Lindholm @ 2013-12-10 14:59 UTC (permalink / raw) To: The development of GNU GRUB [-- Attachment #1: Type: text/plain, Size: 672 bytes --] On Mon, Dec 09, 2013 at 10:17:20PM +0100, Leif Lindholm wrote: > On Mon, Dec 09, 2013 at 08:08:39PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > > > 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. > > Ah, ok - that makes sense then. How about the attached? Compile tested for arm/arm64/i386/x86_64, runtime tested on arm64. / Leif [-- Attachment #2: 0001-efi-mm-make-MAX_USABLE_ADDRESS-platform-specific.patch --] [-- Type: text/x-diff, Size: 4210 bytes --] From 85e5e8576e944c2c7fb5d910f1b739e37f90d9ec Mon Sep 17 00:00:00 2001 From: Leif Lindholm <leif.lindholm@linaro.org> Date: Tue, 10 Dec 2013 12:24:57 +0000 Subject: [PATCH] efi: mm: make MAX_USABLE_ADDRESS platform-specific --- ChangeLog | 5 +++++ grub-core/kern/efi/mm.c | 12 ++++-------- include/grub/arm/efi/memory.h | 5 +++++ include/grub/arm64/efi/memory.h | 5 +++++ include/grub/i386/efi/memory.h | 5 +++++ include/grub/ia64/efi/memory.h | 5 +++++ include/grub/x86_64/efi/memory.h | 9 +++++++++ 7 files changed, 38 insertions(+), 8 deletions(-) diff --git a/ChangeLog b/ChangeLog index aa4c05c..fef366a 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2013-12-10 Leif Lindholm <leif.lindholm@linaro.org> + + * make MAX_USABLE_ADDRESS platform-specific + * grub-core/kern/efi/mm.c: add Vladimir's new BYTES_TO_PAGES_DOWN macro. + 2013-12-09 Jon McCune <jonmccune@google.com> * Add --no-rs-codes flag to optionally disable reed-solomon codes diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c index 6e9dace..3ba69f8 100644 --- a/grub-core/kern/efi/mm.c +++ b/grub-core/kern/efi/mm.c @@ -21,6 +21,7 @@ #include <grub/mm.h> #include <grub/efi/api.h> #include <grub/efi/efi.h> +#include <grub/cpu/efi/memory.h> #if defined (__i386__) || defined (__x86_64__) #include <grub/pci.h> @@ -30,14 +31,9 @@ ((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__) -#define MAX_USABLE_ADDRESS 0xffffffff -#else -#define MAX_USABLE_ADDRESS 0x7fffffff -#endif - /* The size of a memory map obtained from the firmware. This must be a multiplier of 4KB. */ #define MEMORY_MAP_SIZE 0x3000 @@ -343,9 +339,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 diff --git a/include/grub/arm/efi/memory.h b/include/grub/arm/efi/memory.h index c9a61bb..1968b3b 100644 --- a/include/grub/arm/efi/memory.h +++ b/include/grub/arm/efi/memory.h @@ -1 +1,6 @@ +#ifndef GRUB_MEMORY_CPU_HEADER #include <grub/efi/memory.h> + +#define MAX_USABLE_ADDRESS 0xffffffff + +#endif /* ! GRUB_MEMORY_CPU_HEADER */ diff --git a/include/grub/arm64/efi/memory.h b/include/grub/arm64/efi/memory.h index c9a61bb..8340083 100644 --- a/include/grub/arm64/efi/memory.h +++ b/include/grub/arm64/efi/memory.h @@ -1 +1,6 @@ +#ifndef GRUB_MEMORY_CPU_HEADER #include <grub/efi/memory.h> + +#define MAX_USABLE_ADDRESS 0xffffffffffffULL + +#endif /* ! GRUB_MEMORY_CPU_HEADER */ diff --git a/include/grub/i386/efi/memory.h b/include/grub/i386/efi/memory.h index c9a61bb..1968b3b 100644 --- a/include/grub/i386/efi/memory.h +++ b/include/grub/i386/efi/memory.h @@ -1 +1,6 @@ +#ifndef GRUB_MEMORY_CPU_HEADER #include <grub/efi/memory.h> + +#define MAX_USABLE_ADDRESS 0xffffffff + +#endif /* ! GRUB_MEMORY_CPU_HEADER */ diff --git a/include/grub/ia64/efi/memory.h b/include/grub/ia64/efi/memory.h index c9a61bb..1968b3b 100644 --- a/include/grub/ia64/efi/memory.h +++ b/include/grub/ia64/efi/memory.h @@ -1 +1,6 @@ +#ifndef GRUB_MEMORY_CPU_HEADER #include <grub/efi/memory.h> + +#define MAX_USABLE_ADDRESS 0xffffffff + +#endif /* ! GRUB_MEMORY_CPU_HEADER */ diff --git a/include/grub/x86_64/efi/memory.h b/include/grub/x86_64/efi/memory.h index c9a61bb..ed1e640 100644 --- a/include/grub/x86_64/efi/memory.h +++ b/include/grub/x86_64/efi/memory.h @@ -1 +1,10 @@ +#ifndef GRUB_MEMORY_CPU_HEADER #include <grub/efi/memory.h> + +#if defined (__code_model_large__) +#define MAX_USABLE_ADDRESS 0xffffffff +#else +#define MAX_USABLE_ADDRESS 0x7fffffff +#endif + +#endif /* ! GRUB_MEMORY_CPU_HEADER */ -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: kern/efi/mm.c - MAX_USABLE_ADDRESS 2013-12-10 14:59 ` Leif Lindholm @ 2013-12-10 16:00 ` Vladimir 'φ-coder/phcoder' Serbinenko 2013-12-10 17:15 ` Leif Lindholm 0 siblings, 1 reply; 9+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-10 16:00 UTC (permalink / raw) To: The development of GNU GRUB [-- Attachment #1: Type: text/plain, Size: 1083 bytes --] On 10.12.2013 15:59, Leif Lindholm wrote: > On Mon, Dec 09, 2013 at 10:17:20PM +0100, Leif Lindholm wrote: >> On Mon, Dec 09, 2013 at 08:08:39PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >>>> 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. >> >> Ah, ok - that makes sense then. > > How about the attached? > You need to prefix define with GRUB_EFI_ as soon as it's a global define and not limited to one file. Otherwise patch looks good. Can you send corrected version? > Compile tested for arm/arm64/i386/x86_64, runtime tested on arm64. > > / > Leif > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kern/efi/mm.c - MAX_USABLE_ADDRESS 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 0 siblings, 1 reply; 9+ messages in thread From: Leif Lindholm @ 2013-12-10 17:15 UTC (permalink / raw) To: The development of GNU GRUB [-- Attachment #1: Type: text/plain, Size: 397 bytes --] On Tue, Dec 10, 2013 at 05:00:28PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > > How about the attached? > > > You need to prefix define with GRUB_EFI_ as soon as it's a global define > and not limited to one file. Otherwise patch looks good. Can you send > corrected version? Attached. > > Compile tested for arm/arm64/i386/x86_64, runtime tested on arm64. Same again. / Leif [-- Attachment #2: 0001-efi-mm-make-MAX_USABLE_ADDRESS-platform-specific.patch --] [-- Type: text/x-diff, Size: 5707 bytes --] From 09d798628d88542b2af361d5898b179efa2194b3 Mon Sep 17 00:00:00 2001 From: Leif Lindholm <leif.lindholm@linaro.org> Date: Tue, 10 Dec 2013 12:24:57 +0000 Subject: [PATCH] efi: mm: make MAX_USABLE_ADDRESS platform-specific --- ChangeLog | 5 +++++ grub-core/kern/efi/mm.c | 20 ++++++++------------ include/grub/arm/efi/memory.h | 5 +++++ include/grub/arm64/efi/memory.h | 5 +++++ include/grub/i386/efi/memory.h | 5 +++++ include/grub/ia64/efi/memory.h | 5 +++++ include/grub/x86_64/efi/memory.h | 9 +++++++++ 7 files changed, 42 insertions(+), 12 deletions(-) diff --git a/ChangeLog b/ChangeLog index b706eb5..62fdb03 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,10 @@ 2013-12-10 Leif Lindholm <leif.lindholm@linaro.org> + * make MAX_USABLE_ADDRESS platform-specific + * grub-core/kern/efi/mm.c: add Vladimir's new BYTES_TO_PAGES_DOWN macro. + +2013-12-10 Leif Lindholm <leif.lindholm@linaro.org> + * grub-core/lib/fdt.c: change memcpy => grub_memcpy 2013-12-09 Jon McCune <jonmccune@google.com> diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c index 6e9dace..be37afd 100644 --- a/grub-core/kern/efi/mm.c +++ b/grub-core/kern/efi/mm.c @@ -21,6 +21,7 @@ #include <grub/mm.h> #include <grub/efi/api.h> #include <grub/efi/efi.h> +#include <grub/cpu/efi/memory.h> #if defined (__i386__) || defined (__x86_64__) #include <grub/pci.h> @@ -30,14 +31,9 @@ ((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__) -#define MAX_USABLE_ADDRESS 0xffffffff -#else -#define MAX_USABLE_ADDRESS 0x7fffffff -#endif - /* The size of a memory map obtained from the firmware. This must be a multiplier of 4KB. */ #define MEMORY_MAP_SIZE 0x3000 @@ -64,7 +60,7 @@ grub_efi_allocate_pages (grub_efi_physical_address_t address, #if 1 /* Limit the memory access to less than 4GB for 32-bit platforms. */ - if (address > MAX_USABLE_ADDRESS) + if (address > GRUB_EFI_MAX_USABLE_ADDRESS) return 0; #endif @@ -72,7 +68,7 @@ grub_efi_allocate_pages (grub_efi_physical_address_t address, if (address == 0) { type = GRUB_EFI_ALLOCATE_MAX_ADDRESS; - address = MAX_USABLE_ADDRESS; + address = GRUB_EFI_MAX_USABLE_ADDRESS; } else type = GRUB_EFI_ALLOCATE_ADDRESS; @@ -92,7 +88,7 @@ grub_efi_allocate_pages (grub_efi_physical_address_t address, { /* Uggh, the address 0 was allocated... This is too annoying, so reallocate another one. */ - address = MAX_USABLE_ADDRESS; + address = GRUB_EFI_MAX_USABLE_ADDRESS; status = efi_call_4 (b->allocate_pages, type, GRUB_EFI_LOADER_DATA, pages, &address); grub_efi_free_pages (0, pages); if (status != GRUB_EFI_SUCCESS) @@ -325,7 +321,7 @@ filter_memory_map (grub_efi_memory_descriptor_t *memory_map, { if (desc->type == GRUB_EFI_CONVENTIONAL_MEMORY #if 1 - && desc->physical_start <= MAX_USABLE_ADDRESS + && desc->physical_start <= GRUB_EFI_MAX_USABLE_ADDRESS #endif && desc->physical_start + PAGES_TO_BYTES (desc->num_pages) > 0x100000 && desc->num_pages != 0) @@ -343,9 +339,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 (GRUB_EFI_MAX_USABLE_ADDRESS)) filtered_desc->num_pages - = (BYTES_TO_PAGES (MAX_USABLE_ADDRESS+1LL) + = (BYTES_TO_PAGES_DOWN (GRUB_EFI_MAX_USABLE_ADDRESS) - BYTES_TO_PAGES (filtered_desc->physical_start)); #endif diff --git a/include/grub/arm/efi/memory.h b/include/grub/arm/efi/memory.h index c9a61bb..2c64918 100644 --- a/include/grub/arm/efi/memory.h +++ b/include/grub/arm/efi/memory.h @@ -1 +1,6 @@ +#ifndef GRUB_MEMORY_CPU_HEADER #include <grub/efi/memory.h> + +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffff + +#endif /* ! GRUB_MEMORY_CPU_HEADER */ diff --git a/include/grub/arm64/efi/memory.h b/include/grub/arm64/efi/memory.h index c9a61bb..c6cb324 100644 --- a/include/grub/arm64/efi/memory.h +++ b/include/grub/arm64/efi/memory.h @@ -1 +1,6 @@ +#ifndef GRUB_MEMORY_CPU_HEADER #include <grub/efi/memory.h> + +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffffffffULL + +#endif /* ! GRUB_MEMORY_CPU_HEADER */ diff --git a/include/grub/i386/efi/memory.h b/include/grub/i386/efi/memory.h index c9a61bb..2c64918 100644 --- a/include/grub/i386/efi/memory.h +++ b/include/grub/i386/efi/memory.h @@ -1 +1,6 @@ +#ifndef GRUB_MEMORY_CPU_HEADER #include <grub/efi/memory.h> + +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffff + +#endif /* ! GRUB_MEMORY_CPU_HEADER */ diff --git a/include/grub/ia64/efi/memory.h b/include/grub/ia64/efi/memory.h index c9a61bb..2c64918 100644 --- a/include/grub/ia64/efi/memory.h +++ b/include/grub/ia64/efi/memory.h @@ -1 +1,6 @@ +#ifndef GRUB_MEMORY_CPU_HEADER #include <grub/efi/memory.h> + +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffff + +#endif /* ! GRUB_MEMORY_CPU_HEADER */ diff --git a/include/grub/x86_64/efi/memory.h b/include/grub/x86_64/efi/memory.h index c9a61bb..46e9145 100644 --- a/include/grub/x86_64/efi/memory.h +++ b/include/grub/x86_64/efi/memory.h @@ -1 +1,10 @@ +#ifndef GRUB_MEMORY_CPU_HEADER #include <grub/efi/memory.h> + +#if defined (__code_model_large__) +#define GRUB_EFI_MAX_USABLE_ADDRESS 0xffffffff +#else +#define GRUB_EFI_MAX_USABLE_ADDRESS 0x7fffffff +#endif + +#endif /* ! GRUB_MEMORY_CPU_HEADER */ -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: kern/efi/mm.c - MAX_USABLE_ADDRESS 2013-12-10 17:15 ` Leif Lindholm @ 2013-12-10 18:00 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 0 replies; 9+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2013-12-10 18:00 UTC (permalink / raw) To: The development of GNU GRUB [-- Attachment #1: Type: text/plain, Size: 659 bytes --] Go ahead. On 10.12.2013 18:15, Leif Lindholm wrote: > On Tue, Dec 10, 2013 at 05:00:28PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >>> How about the attached? >>> >> You need to prefix define with GRUB_EFI_ as soon as it's a global define >> and not limited to one file. Otherwise patch looks good. Can you send >> corrected version? > > Attached. > >>> Compile tested for arm/arm64/i386/x86_64, runtime tested on arm64. > > Same again. > > / > Leif > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 291 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-12-10 18:01 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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).