From: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
"linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Leif Lindholm
<leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Matt Fleming
<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied
Date: Tue, 29 Jul 2014 15:20:21 -0400 [thread overview]
Message-ID: <1406661621.753.34.camel@deneb.redhat.com> (raw)
In-Reply-To: <CAKv+Gu-3J+1u1vcCAOgfq6JRfSc7_pykaV2OwGRNSOORTS1=1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, 2014-07-29 at 20:46 +0200, Ard Biesheuvel wrote:
> On 29 July 2014 20:27, Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Tue, 2014-07-29 at 20:17 +0200, Ard Biesheuvel wrote:
> >> On 29 July 2014 17:29, Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> >> ---
> >> >> 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.
I'm not following. I would say there is no point in not doing that.
You have a patch which causes a build warning. Let's avoid that
unless there's a good reason not too. In this case, it seems easy
enough to avoid unless I'm missing something.
>
> 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?
Breaking bisect would be really bad. I think all three should be
pulled from the same tree. What's wrong with getting an ack from
Catalin or Will on the first patch and having all three go through
tip? Patch one is needed for EFI boot functionality even if it isn't
specifically EFI code. This won't be the last time this sort of
situation arises.
>
> >>
> >> > Otherwise:
> >> >
> >> > Acked-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >> >
> >>
> >> 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;
> >> >> }
> >> >>
> >> >>
> >> >
> >> >
> >
> >
WARNING: multiple messages have this Message-ID (diff)
From: msalter@redhat.com (Mark Salter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied
Date: Tue, 29 Jul 2014 15:20:21 -0400 [thread overview]
Message-ID: <1406661621.753.34.camel@deneb.redhat.com> (raw)
In-Reply-To: <CAKv+Gu-3J+1u1vcCAOgfq6JRfSc7_pykaV2OwGRNSOORTS1=1A@mail.gmail.com>
On Tue, 2014-07-29 at 20:46 +0200, Ard Biesheuvel wrote:
> On 29 July 2014 20:27, Mark Salter <msalter@redhat.com> wrote:
> > On Tue, 2014-07-29 at 20:17 +0200, Ard Biesheuvel wrote:
> >> On 29 July 2014 17:29, Mark Salter <msalter@redhat.com> 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@linaro.org>
> >> >> ---
> >> >> 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.
I'm not following. I would say there is no point in not doing that.
You have a patch which causes a build warning. Let's avoid that
unless there's a good reason not too. In this case, it seems easy
enough to avoid unless I'm missing something.
>
> 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?
Breaking bisect would be really bad. I think all three should be
pulled from the same tree. What's wrong with getting an ack from
Catalin or Will on the first patch and having all three go through
tip? Patch one is needed for EFI boot functionality even if it isn't
specifically EFI code. This won't be the last time this sort of
situation arises.
>
> >>
> >> > Otherwise:
> >> >
> >> > Acked-by: Mark Salter <msalter@redhat.com>
> >> >
> >>
> >> 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;
> >> >> }
> >> >>
> >> >>
> >> >
> >> >
> >
> >
next prev parent reply other threads:[~2014-07-29 19:20 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 10:49 [PATCH 0/3] arm64/efi: improve TEXT_OFFSET handling Ard Biesheuvel
2014-07-29 10:49 ` Ard Biesheuvel
[not found] ` <1406630950-32432-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-07-29 10:49 ` [PATCH 1/3] arm64: spin-table: handle unmapped cpu-release-addrs Ard Biesheuvel
2014-07-29 10:49 ` Ard Biesheuvel
[not found] ` <1406630950-32432-2-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-07-29 15:15 ` Mark Salter
2014-07-29 15:15 ` Mark Salter
[not found] ` <1406646945.753.5.camel-PDpCo7skNiwAicBL8TP8PQ@public.gmane.org>
2014-07-29 15:17 ` Mark Salter
2014-07-29 15:17 ` Mark Salter
2014-07-29 15:20 ` Arnd Bergmann
2014-07-29 15:20 ` Arnd Bergmann
2014-07-29 15:30 ` Mark Salter
2014-07-29 15:30 ` Mark Salter
[not found] ` <1406647824.753.12.camel-PDpCo7skNiwAicBL8TP8PQ@public.gmane.org>
2014-07-29 15:38 ` Arnd Bergmann
2014-07-29 15:38 ` Arnd Bergmann
2014-07-29 16:03 ` Mark Rutland
2014-07-29 16:03 ` Mark Rutland
2014-07-29 16:13 ` Arnd Bergmann
2014-07-29 16:13 ` Arnd Bergmann
2014-07-29 16:18 ` Mark Rutland
2014-07-29 16:18 ` Mark Rutland
2014-07-29 16:24 ` Arnd Bergmann
2014-07-29 16:24 ` Arnd Bergmann
2014-07-29 10:49 ` [PATCH 2/3] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text Ard Biesheuvel
2014-07-29 10:49 ` Ard Biesheuvel
[not found] ` <1406630950-32432-3-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-07-29 15:36 ` Mark Salter
2014-07-29 15:36 ` Mark Salter
2014-07-29 10:49 ` [PATCH 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied Ard Biesheuvel
2014-07-29 10:49 ` Ard Biesheuvel
[not found] ` <1406630950-32432-4-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2014-07-29 15:29 ` Mark Salter
2014-07-29 15:29 ` Mark Salter
[not found] ` <1406647756.753.11.camel-PDpCo7skNiwAicBL8TP8PQ@public.gmane.org>
2014-07-29 18:17 ` Ard Biesheuvel
2014-07-29 18:17 ` Ard Biesheuvel
[not found] ` <CAKv+Gu8Pwi6GuGq9jbGfHyALcJKtAG+KVDcVwpYVCG9ZKrhaPA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-29 18:27 ` Mark Salter
2014-07-29 18:27 ` Mark Salter
[not found] ` <1406658428.753.22.camel-PDpCo7skNiwAicBL8TP8PQ@public.gmane.org>
2014-07-29 18:46 ` Ard Biesheuvel
2014-07-29 18:46 ` Ard Biesheuvel
[not found] ` <CAKv+Gu-3J+1u1vcCAOgfq6JRfSc7_pykaV2OwGRNSOORTS1=1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-07-29 19:20 ` Mark Salter [this message]
2014-07-29 19:20 ` Mark Salter
[not found] ` <1406661621.753.34.camel-PDpCo7skNiwAicBL8TP8PQ@public.gmane.org>
2014-07-29 19:33 ` Ard Biesheuvel
2014-07-29 19:33 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1406661621.753.34.camel@deneb.redhat.com \
--to=msalter-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.