* 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: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 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 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).