diff mbox

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

Message ID 1406717944-24725-4-git-send-email-ard.biesheuvel@linaro.org
State Superseded
Headers show

Commit Message

Ard Biesheuvel July 30, 2014, 10:59 a.m. UTC 
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@linaro.org>
Acked-by: Mark Salter <msalter@redhat.com>
---
 arch/arm64/kernel/efi-stub.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

Comments

Mark Rutland Aug. 14, 2014, 11:32 a.m. UTC | #1 
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@linaro.org>
> Acked-by: Mark Salter <msalter@redhat.com>

Acked-by: Mark Rutland <mark.rutland@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
> 
>
Matt Fleming Aug. 20, 2014, 5:10 p.m. UTC | #2 
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@linaro.org>
> > Acked-by: Mark Salter <msalter@redhat.com>
> 
> Acked-by: Mark Rutland <mark.rutland@arm.com>

Ard, who's picking this up?
Mark Rutland Aug. 20, 2014, 5:35 p.m. UTC | #3 
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@linaro.org>
> > > Acked-by: Mark Salter <msalter@redhat.com>
> > 
> > Acked-by: Mark Rutland <mark.rutland@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=devel&id=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
Ard Biesheuvel Aug. 21, 2014, 8 a.m. UTC | #4 
On 20 August 2014 19:35, Mark Rutland <mark.rutland@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.biesheuvel@linaro.org>
>> > > Acked-by: Mark Salter <msalter@redhat.com>
>> >
>> > Acked-by: Mark Rutland <mark.rutland@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(-)
Matt Fleming Aug. 21, 2014, 9:22 a.m. UTC | #5 
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.
Jon Masters Sept. 9, 2014, 7:39 p.m. UTC | #6 
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+yROfE0A@public.gmane.org>
>>>> Acked-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>
>>> Acked-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@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.
Will Deacon Sept. 10, 2014, 8:39 a.m. UTC | #7 
On Tue, Sep 09, 2014 at 08:39:38PM +0100, Jon Masters wrote:
> 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+yROfE0A@public.gmane.org>
> >>>> Acked-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>>
> >>> Acked-by: Mark Rutland <mark.rutland-5wv7dgnIgG8@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.

Yes, it's queued for 3.18 and should be in linux-next too. This isn't a
regression, so you'll just have to sit tight.

Will
diff mbox

Patch

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;
 	}