Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-09-09 Thread Jon Masters
On 08/20/2014 01:35 PM, Mark Rutland wrote:
 On Wed, Aug 20, 2014 at 06:10:57PM +0100, Matt Fleming wrote:
 On Thu, 14 Aug, at 12:32:05PM, Mark Rutland wrote:
 On Wed, Jul 30, 2014 at 11:59:04AM +0100, Ard Biesheuvel wrote:
 If we cannot relocate the kernel Image to its preferred offset of base of 
 DRAM
 plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB 
 boundary plus
 TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
 proceed normally otherwise.

 Signed-off-by: Ard Biesheuvel 
 ard.biesheuvel-qsej5fyqhm4dnm+yrof...@public.gmane.org
 Acked-by: Mark Salter msalter-h+wxahxf7alqt0dzr+a...@public.gmane.org

 Acked-by: Mark Rutland mark.rutland-5wv7dgni...@public.gmane.org

 Ard, who's picking this up?
 
 Will's already taken this into arm64/devel [1,2] with the intention of
 waiting for v3.18 [3]. Per Leif's comment [4] that might have to be
 bumped.

So what's the plan with this series? Waiting for 3.18? The problem is
that this patch series needs to be pulled for any platform with an EFI
firmware located at DRAM base (e.g. AMD Seattle) as was noted before.

Jon.

--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-08-21 Thread Ard Biesheuvel
On 20 August 2014 19:35, Mark Rutland mark.rutl...@arm.com wrote:
 On Wed, Aug 20, 2014 at 06:10:57PM +0100, Matt Fleming wrote:
 On Thu, 14 Aug, at 12:32:05PM, Mark Rutland wrote:
  On Wed, Jul 30, 2014 at 11:59:04AM +0100, Ard Biesheuvel wrote:
   If we cannot relocate the kernel Image to its preferred offset of base 
   of DRAM
   plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB 
   boundary plus
   TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
   proceed normally otherwise.
  
   Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
   Acked-by: Mark Salter msal...@redhat.com
 
  Acked-by: Mark Rutland mark.rutl...@arm.com

 Ard, who's picking this up?


Hey Matt,

These patches mostly touch non-EFI specific files under arch/arm64, so
to prevent conflicts, it makes sense for the arm64 tree to take them.

 arch/arm64/kernel/efi-stub.c   | 18 ++
 arch/arm64/kernel/head.S   |  6 +++---
 arch/arm64/kernel/smp_spin_table.c | 21 -
 3 files changed, 25 insertions(+), 20 deletions(-)

-- 
Ard.


 Will's already taken this into arm64/devel [1,2] with the intention of
 waiting for v3.18 [3]. Per Leif's comment [4] that might have to be
 bumped.

 Will?

 Mark.

 [1] 
 https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/commit/?h=devel
 [2] 
 https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/commit/?h=develid=12f002aa8d96b90e6e37cc2b0d9a6a3cacdf8ef5
 [3] 
 http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279655.html
 [4] 
 http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279771.html
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-08-21 Thread Matt Fleming
On Thu, 21 Aug, at 10:00:40AM, Ard Biesheuvel wrote:
 
 Hey Matt,
 
 These patches mostly touch non-EFI specific files under arch/arm64, so
 to prevent conflicts, it makes sense for the arm64 tree to take them.

OK great. Thanks guys.

-- 
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-08-20 Thread Matt Fleming
On Thu, 14 Aug, at 12:32:05PM, Mark Rutland wrote:
 On Wed, Jul 30, 2014 at 11:59:04AM +0100, Ard Biesheuvel wrote:
  If we cannot relocate the kernel Image to its preferred offset of base of 
  DRAM
  plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary 
  plus
  TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
  proceed normally otherwise.
  
  Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
  Acked-by: Mark Salter msal...@redhat.com
 
 Acked-by: Mark Rutland mark.rutl...@arm.com

Ard, who's picking this up?

-- 
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-08-20 Thread Mark Rutland
On Wed, Aug 20, 2014 at 06:10:57PM +0100, Matt Fleming wrote:
 On Thu, 14 Aug, at 12:32:05PM, Mark Rutland wrote:
  On Wed, Jul 30, 2014 at 11:59:04AM +0100, Ard Biesheuvel wrote:
   If we cannot relocate the kernel Image to its preferred offset of base of 
   DRAM
   plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB 
   boundary plus
   TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
   proceed normally otherwise.
   
   Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
   Acked-by: Mark Salter msal...@redhat.com
  
  Acked-by: Mark Rutland mark.rutl...@arm.com
 
 Ard, who's picking this up?

Will's already taken this into arm64/devel [1,2] with the intention of
waiting for v3.18 [3]. Per Leif's comment [4] that might have to be
bumped.

Will?

Mark.

[1] https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/commit/?h=devel
[2] 
https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/commit/?h=develid=12f002aa8d96b90e6e37cc2b0d9a6a3cacdf8ef5
[3] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279655.html
[4] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279771.html
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-08-14 Thread Mark Rutland
On Wed, Jul 30, 2014 at 11:59:04AM +0100, Ard Biesheuvel wrote:
 If we cannot relocate the kernel Image to its preferred offset of base of DRAM
 plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary 
 plus
 TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
 proceed normally otherwise.
 
 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
 Acked-by: Mark Salter msal...@redhat.com

Acked-by: Mark Rutland mark.rutl...@arm.com

 ---
  arch/arm64/kernel/efi-stub.c | 16 ++--
  1 file changed, 6 insertions(+), 10 deletions(-)
 
 diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
 index 1317fef8dde9..d27dd982ff26 100644
 --- a/arch/arm64/kernel/efi-stub.c
 +++ b/arch/arm64/kernel/efi-stub.c
 @@ -28,20 +28,16 @@ efi_status_t handle_kernel_image(efi_system_table_t 
 *sys_table,
   kernel_size = _edata - _text;
   if (*image_addr != (dram_base + TEXT_OFFSET)) {
   kernel_memsize = kernel_size + (_end - _edata);
 - status = efi_relocate_kernel(sys_table, image_addr,
 -  kernel_size, kernel_memsize,
 -  dram_base + TEXT_OFFSET,
 -  PAGE_SIZE);
 + status = efi_low_alloc(sys_table, kernel_memsize + TEXT_OFFSET,
 +SZ_2M, reserve_addr);
   if (status != EFI_SUCCESS) {
   pr_efi_err(sys_table, Failed to relocate kernel\n);
   return status;
   }
 - if (*image_addr != (dram_base + TEXT_OFFSET)) {
 - pr_efi_err(sys_table, Failed to alloc kernel 
 memory\n);
 - efi_free(sys_table, kernel_memsize, *image_addr);
 - return EFI_LOAD_ERROR;
 - }
 - *image_size = kernel_memsize;
 + memcpy((void *)*reserve_addr + TEXT_OFFSET, (void *)*image_addr,
 +kernel_size);
 + *image_addr = *reserve_addr + TEXT_OFFSET;
 + *reserve_size = kernel_memsize + TEXT_OFFSET;
   }
  
  
 -- 
 1.8.3.2
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied

2014-07-30 Thread Ard Biesheuvel
If we cannot relocate the kernel Image to its preferred offset of base of DRAM
plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary plus
TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
proceed normally otherwise.

Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
Acked-by: Mark Salter msal...@redhat.com
---
 arch/arm64/kernel/efi-stub.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
index 1317fef8dde9..d27dd982ff26 100644
--- a/arch/arm64/kernel/efi-stub.c
+++ b/arch/arm64/kernel/efi-stub.c
@@ -28,20 +28,16 @@ efi_status_t handle_kernel_image(efi_system_table_t 
*sys_table,
kernel_size = _edata - _text;
if (*image_addr != (dram_base + TEXT_OFFSET)) {
kernel_memsize = kernel_size + (_end - _edata);
-   status = efi_relocate_kernel(sys_table, image_addr,
-kernel_size, kernel_memsize,
-dram_base + TEXT_OFFSET,
-PAGE_SIZE);
+   status = efi_low_alloc(sys_table, kernel_memsize + TEXT_OFFSET,
+  SZ_2M, reserve_addr);
if (status != EFI_SUCCESS) {
pr_efi_err(sys_table, Failed to relocate kernel\n);
return status;
}
-   if (*image_addr != (dram_base + TEXT_OFFSET)) {
-   pr_efi_err(sys_table, Failed to alloc kernel 
memory\n);
-   efi_free(sys_table, kernel_memsize, *image_addr);
-   return EFI_LOAD_ERROR;
-   }
-   *image_size = kernel_memsize;
+   memcpy((void *)*reserve_addr + TEXT_OFFSET, (void *)*image_addr,
+  kernel_size);
+   *image_addr = *reserve_addr + TEXT_OFFSET;
+   *reserve_size = kernel_memsize + TEXT_OFFSET;
}
 
 
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-efi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html