On 29 July 2014 20:27, Mark Salter <msalter@xxxxxxxxxx> wrote:
> On Tue, 2014-07-29 at 20:17 +0200, Ard Biesheuvel wrote:
>> On 29 July 2014 17:29, Mark Salter <msalter@xxxxxxxxxx> wrote:
>> > On Tue, 2014-07-29 at 12:49 +0200, 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@xxxxxxxxxx>
>> >> ---
>> >> arch/arm64/kernel/efi-stub.c | 16 ++++++----------
>> >> 1 file changed, 6 insertions(+), 10 deletions(-)
>> >
>> > Tested on Mustang (with loss of 2MB free memory).
>> >
>>
>> Great, thanks!
>>
>> >>
>> >> diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
>> >> index 60e98a639ac5..460c00c41e57 100644
>> >> --- a/arch/arm64/kernel/efi-stub.c
>> >> +++ b/arch/arm64/kernel/efi-stub.c
>> >> @@ -60,20 +60,16 @@ static 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);
>> >
>> > Can we make efi_relocate_kernel static inline to get rid
>> > of the "defined but unused" warning?
>> >
>>
>> I have some patches pending in the EFI tree to turn the stub into a
>> static library, and that already takes care of this issue.
>
> That's fine if the static library stub patch goes in first. If this
> patch goes in first, then let's avoid the warning since it is easy
> to do.
>
My idea was to ask Matt to take patches #2 and #3. I may have to fix
them up slightly to apply correctly, but that's fine. Changing
efi_relocate_kernel to static inline would need to go through Matt's
tree as well, so there's probably no point in doing that in any case.
Patch #1 needs to go through the arm64, I guess. This means UEFI boot
on APM Mustang will be broken during the short time between the
x86/tip tree and the arm64 tree being merged for 3.17 (assuming 3.17
is still open). I think we should be able to tolerate that, right?
>>
>> > Otherwise:
>> >
>> > Acked-by: Mark Salter <msalter@xxxxxxxxxx>
>> >
>>
>> Cheers,
>> Ard.
>>
>>
>>
>> >> + 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_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;
>> >> }
>> >>
>> >>
>> >
>> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
