Hi Ard,
On Mon, Jul 14, 2014 at 05:17:51PM +0100, Ard Biesheuvel wrote:
> The EFI stub for arm64 needs to behave like an ordinary bootloader in the
> sense
> that it needs to use the EFI environment and the Image header at runtime and
> not rely on the linker or preprocessor to produce values for
Hi Ard,
On Mon, Jul 14, 2014 at 05:17:50PM +0100, Ard Biesheuvel wrote:
> In order to be able to interpret the Image header from C code, we need a
> struct definition that reflects the specification for Image headers as laid
> out in Documentation/arm64/booting.txt.
>
> Signed-off-by: Ard Biesheu
On Mon, Jul 14, 2014 at 06:35:32PM +0100, Ard Biesheuvel wrote:
> On 14 July 2014 18:54, Mark Rutland wrote:
> > Hi Ard,
> >
> > On Mon, Jul 14, 2014 at 05:17:51PM +0100, Ard Biesheuvel wrote:
> >> The EFI stub for arm64 needs to behave like an ordinary bootloader i
Hi Ard,
[...]
> >> >> diff --git a/arch/arm64/kernel/efi-stub.c b/arch/arm64/kernel/efi-stub.c
> >> >> index 9b61d66e2d20..4ba90b2ef677 100644
> >> >> --- a/arch/arm64/kernel/efi-stub.c
> >> >> +++ b/arch/arm64/kernel/efi-stub.c
> >> >> @@ -11,8 +11,7 @@
> >> >> */
> >> >> #include
> >> >> #
Hi Ard,
On Tue, Jul 15, 2014 at 10:10:02AM +0100, Ard Biesheuvel wrote:
> After the EFI stub has done its business, it jumps into the kernel by
> branching
> to offset #0 of the loaded Image, which is where it expects to find the header
> containing a 'branch to stext' instruction.
> However, the
ar map, but that's a lot more work.
Cheers,
Mark.
>8
>From 73812b654a07f497f71bd38dfb4a6753fb0ad23e Mon Sep 17 00:00:00 2001
From: Mark Rutland
Date: Tue, 15 Jul 2014 11:32:53 +0100
Subject: [PATCH] arm64: spin-table: handle unmapped cpu-release-addrs
In certain cases the cpu-release-addr o
On Tue, Jul 15, 2014 at 11:02:22AM +0100, Leif Lindholm wrote:
> On Mon, Jul 14, 2014 at 02:40:48PM -0400, Mark Salter wrote:
> > On Mon, 2014-07-14 at 17:25 +0200, Ard Biesheuvel wrote:
> > > If we fail to relocate the kernel Image to its preferred offset of
> > > TEXT_OFFSET
> > > bytes above th
> >> diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
> >> index 619b1dd7bcde..6ef541731d9e 100644
> >> --- a/arch/arm64/kernel/efi-entry.S
> >> +++ b/arch/arm64/kernel/efi-entry.S
> >> @@ -61,7 +61,7 @@ ENTRY(efi_stub_entry)
> >>*/
> >> mov x20, x0
On Tue, Jul 15, 2014 at 12:49:07PM +0100, Ard Biesheuvel wrote:
> On 15 July 2014 13:31, Mark Rutland wrote:
> >> >> diff --git a/arch/arm64/kernel/efi-entry.S
> >> >> b/arch/arm64/kernel/efi-entry.S
> >> >> index 619b1dd7bcde..6ef541731d9e 10
On Tue, Jul 15, 2014 at 03:23:26PM +0100, Mark Salter wrote:
> On Tue, 2014-07-15 at 14:54 +0100, Leif Lindholm wrote:
> > On Tue, Jul 15, 2014 at 09:11:00AM -0400, Mark Salter wrote:
> > > On Tue, 2014-07-15 at 11:02 +0100, Leif Lindholm wrote:
> > > > > @@ -273,6 +282,10 @@ static void __init fre
Hi Ard,
On Tue, Jul 15, 2014 at 05:50:30PM +0100, Ard Biesheuvel wrote:
> The EFI loader may load Image at any available offset. This means Image may
> reside very close to or at the base of DRAM, in which case the relocation
> done by efi_entry() results in Image being moved up in memory, which i
On Wed, Jul 16, 2014 at 03:51:37PM +0100, Mark Salter wrote:
> On Tue, 2014-07-15 at 12:58 +0200, Ard Biesheuvel wrote:
> > After the EFI stub has done its business, it jumps into the kernel by
> > branching
> > to offset #0 of the loaded Image, which is where it expects to find the
> > header
>
Hi Ard,
This is certainly a neat feature, and I definitely want to be able to
boot BE kernels via UEFI.
However, I'm wary of calling EFI in a physical (i.e. idmap with dcaches
off) context. I'm not sure anyone else does that, and I'm not sure
whether that's going to work (both because of the cach
a more
general plan.
> Reported-by: Mark Rutland
> Signed-off-by: Leif Lindholm
> ---
> arch/arm64/kernel/efi.c |2 ++
> arch/arm64/mm/init.c|4 +++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/k
On Tue, Jul 29, 2014 at 04:20:46PM +0100, Arnd Bergmann wrote:
> On Tuesday 29 July 2014 11:15:45 Mark Salter wrote:
> > > -
> > > - __flush_dcache_area(release_addr, sizeof(release_addr[0]));
> > > + writeq_relaxed(__pa(secondary_holding_pen), release_addr);
> > > + __flush_dcache_area
On Tue, Jul 29, 2014 at 05:13:07PM +0100, Arnd Bergmann wrote:
> On Tuesday 29 July 2014 17:03:03 Mark Rutland wrote:
> > On Tue, Jul 29, 2014 at 04:20:46PM +0100, Arnd Bergmann wrote:
> > > On Tuesday 29 July 2014 11:15:45 Mark Salter wrote:
> > > > > -
&g
On Wed, Jul 30, 2014 at 01:00:40PM +0100, Ard Biesheuvel wrote:
> On 30 July 2014 13:30, Will Deacon wrote:
> > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
> >> From: Mark Rutland
> >>
> >> In certain cases the cpu-release-addr of a CPU may
On Wed, Jul 30, 2014 at 01:42:58PM +0100, Will Deacon wrote:
> On Wed, Jul 30, 2014 at 01:30:29PM +0100, Mark Rutland wrote:
> > On Wed, Jul 30, 2014 at 01:00:40PM +0100, Ard Biesheuvel wrote:
> > > On 30 July 2014 13:30, Will Deacon wrote:
> > > > On Wed, Jul 30,
On Thu, Jul 31, 2014 at 10:45:15AM +0100, Will Deacon wrote:
> On Wed, Jul 30, 2014 at 08:17:02PM +0100, Ard Biesheuvel wrote:
> > ]On 30 July 2014 13:30, Will Deacon wrote:
> > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
> > >> From: Mark Rut
On Thu, Jul 31, 2014 at 11:04:39AM +0100, Will Deacon wrote:
> On Thu, Jul 31, 2014 at 10:58:54AM +0100, Mark Rutland wrote:
> > On Thu, Jul 31, 2014 at 10:45:15AM +0100, Will Deacon wrote:
> > > On Wed, Jul 30, 2014 at 08:17:02PM +0100, Ard Biesheuvel wrote:
> > > >
me and it seems we do the same for x86 as of
c7fb93ec51d4 (x86/efi: Include a .bss section within the PE/COFF
headers). So:
Acked-by: Mark Rutland
> ---
> arch/arm64/kernel/head.S | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/head.S b
end, but we can still
> proceed normally otherwise.
>
> Signed-off-by: Ard Biesheuvel
> Acked-by: Mark Salter
Acked-by: Mark Rutland
> ---
> arch/arm64/kernel/efi-stub.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/ar
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
> > >
del_mem_rsv(fdt, i);
I don't think that's right. Won't the memreserve entries shift down by
one each time we call fdt_del_mem_rsv?
Shouldn't this be something like:
while (fdt_num_mem_rsv(fdt))
fdt_del_mem_rsv(fdt, 0);
Or we could count downwards.
Otherwise, the genera
On Mon, Sep 08, 2014 at 03:21:05PM +0100, Mark Salter wrote:
> On Mon, 2014-09-08 at 15:06 +0100, Mark Rutland wrote:
> > Hi Mark,
> >
> > On Mon, Sep 08, 2014 at 02:31:42PM +0100, Mark Salter wrote:
> > > Commit 86c8b27a01cf:
> > > "arm64: ignore DT
On Tue, Oct 07, 2014 at 06:28:07AM +0100, Guenter Roeck wrote:
> Devicetree bindings are supposed to be operating system independent
> and should thus not describe how a specific functionality is implemented
> in Linux.
>
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rut
On Tue, Oct 07, 2014 at 06:28:09AM +0100, Guenter Roeck wrote:
> Replace reference to pm_power_off (which is an implementation detail)
> and replace it with a more generic description of the driver's functionality.
>
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark R
On Tue, Oct 07, 2014 at 06:28:08AM +0100, Guenter Roeck wrote:
> pm_power_off is an implementation detail. Replace it with a more generic
> description of the driver's functionality.
>
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
Acked-by: Mark Rutland
&
On Tue, Oct 07, 2014 at 05:21:11PM +0100, Rob Landley wrote:
> On 10/07/14 00:28, Guenter Roeck wrote:
> > Devicetree bindings are supposed to be operating system independent
> > and should thus not describe how a specific functionality is implemented
> > in Linux.
>
> So your argument is that lin
Hi Ard,
On Wed, Oct 08, 2014 at 03:11:27PM +0100, Ard Biesheuvel wrote:
> After the EFI stub has done its business, it jumps into the kernel by
> branching to offset #0 of the loaded Image, which is where it expects
> to find the header containing a 'branch to stext' instruction.
>
> However, the
Hi Ard,
On Fri, Oct 10, 2014 at 10:25:24AM +0100, Ard Biesheuvel wrote:
> Position independent AArch64 code needs to be linked and loaded at the same
> relative offset from a 4 KB boundary, or adrp/add and adrp/ldr pairs will
> not work correctly. (This is how PC relative symbol references with a
On Thu, Oct 09, 2014 at 08:03:52PM +0100, Ard Biesheuvel wrote:
> On 9 October 2014 19:23, Mark Rutland wrote:
> > Hi Ard,
> >
> > On Wed, Oct 08, 2014 at 03:11:27PM +0100, Ard Biesheuvel wrote:
> >> After the EFI stub has done its business, it jumps into the kernel
On Fri, Oct 10, 2014 at 12:52:32PM +0100, Ard Biesheuvel wrote:
> On 10 October 2014 12:49, Mark Rutland wrote:
> > On Thu, Oct 09, 2014 at 08:03:52PM +0100, Ard Biesheuvel wrote:
> >> On 9 October 2014 19:23, Mark Rutland wrote:
> >> > Hi Ard,
> >> >
[...]
> >> > But if the EFI loader is allowed to load stext at the precise start of
> >> > RAM (or anywhere not in the idmap), in attempting the copy we'd try to
> >> > access unmapped addresses.
> >> >
> >> > So if that's a possibility, we need to shrink the copy to cover stext
> >> > to _edata r
On Fri, Oct 10, 2014 at 02:27:46PM +0100, Ard Biesheuvel wrote:
> On 10 October 2014 15:03, Mark Rutland wrote:
> > [...]
> >
> >> >> > But if the EFI loader is allowed to load stext at the precise start of
> >> >> > RAM (or anywhere no
On Fri, Oct 10, 2014 at 11:37:03AM +0100, Ard Biesheuvel wrote:
> On 10 October 2014 12:33, Mark Rutland wrote:
> > Hi Ard,
> >
> > On Fri, Oct 10, 2014 at 10:25:24AM +0100, Ard Biesheuvel wrote:
> >> Position independent AArch64 code needs to be linked and loaded at
On Fri, Oct 10, 2014 at 03:50:49PM +0100, Ard Biesheuvel wrote:
> On 10 October 2014 16:09, Mark Rutland wrote:
> > On Fri, Oct 10, 2014 at 11:37:03AM +0100, Ard Biesheuvel wrote:
> >> On 10 October 2014 12:33, Mark Rutland wrote:
> >> > Hi Ard,
> >> >
th a
> reference to 'stext_offset'
>
> Signed-off-by: Ard Biesheuvel
Given the constraints you describe above, and prior discussions, this
looks sane to me:
Acked-by: Mark Rutland
Mark.
> ---
> v3:
> - rebased onto 3.17+
> - added spec reference to commit
with a 4 GB reach are emitted)
>
> We need to declare this in the PE/COFF header, otherwise the PE/COFF
> loader may load the Image and invoke the stub at an offset which
> violates this rule.
>
> Reviewed-by: Roy Franz
> Signed-off-by: Ard Biesheuvel
Acked-by: Mark R
On Wed, Oct 22, 2014 at 03:21:47PM +0100, Ard Biesheuvel wrote:
> Memory regions of type ACPI_MEMORY_NVS should be preserved
> by the OS, so make sure we reserve them at boot.
>
> Signed-off-by: Ard Biesheuvel
> ---
> arch/arm64/kernel/efi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --gi
On Wed, Oct 22, 2014 at 06:06:56PM +0100, Mark Salter wrote:
> On Wed, 2014-10-22 at 16:21 +0200, Ard Biesheuvel wrote:
> > On systems that boot via UEFI, all memory nodes are deleted from the
> > device tree, and instead, the size and location of system RAM is derived
> > from the UEFI memory map.
below. It boots happily on my
Juno (with 4KiB pages at least), but I haven't given it much of a stress
test.
I wasn't sure if unusable memory could show up with EFI_MEMORY_WB
attributes. If so, this patch still won't prevent that from being mapped
as cacheable, but that should be
On Tue, Oct 28, 2014 at 04:18:37PM +, Ard Biesheuvel wrote:
> Instead of reserving the memory regions based on which types we know
> need to be reserved, consider only regions of the following types as
> free for general use by the OS:
>
> EFI_LOADER_CODE
> EFI_LOADER_DATA
> EFI_BOOT_SERVICES_
On Tue, Oct 28, 2014 at 05:08:29PM +, Ard Biesheuvel wrote:
> On 28 October 2014 17:47, Mark Rutland wrote:
> > On Tue, Oct 28, 2014 at 04:18:37PM +, Ard Biesheuvel wrote:
> >> Instead of reserving the memory regions based on which types we know
> >> need to
On Tue, Nov 11, 2014 at 05:12:09PM +, Mark Salter wrote:
> On Tue, 2014-11-11 at 10:42 -0500, Mark Salter wrote:
> > On Mon, 2014-11-10 at 08:31 +0100, Ard Biesheuvel wrote:
> > > On 10 November 2014 05:11, Mark Salter wrote:
> > > > On Thu, 2014-11-06 at 15:13 +0100, Ard Biesheuvel wrote:
> >
On Tue, Nov 11, 2014 at 05:55:24PM +, Ard Biesheuvel wrote:
> On 11 November 2014 18:44, Mark Rutland wrote:
> > On Tue, Nov 11, 2014 at 05:12:09PM +, Mark Salter wrote:
> >> On Tue, 2014-11-11 at 10:42 -0500, Mark Salter wrote:
> >> > On Mon, 2014-11-10
Hi Ard,
I have a few (minor) comments below.
On Mon, Dec 22, 2014 at 10:59:02AM +, Ard Biesheuvel wrote:
> In order to support kexec, the kernel needs to be able to deal with the
> state of the UEFI firmware after SetVirtualAddressMap() has been called.
> To avoid having separate code paths f
Hi Ard,
On Thu, Jan 08, 2015 at 05:51:47PM +, Ard Biesheuvel wrote:
> This fixes two minor issues in the implementation of get_memory_map():
> - Currently, it assumes that sizeof(efi_memory_desc_t) == desc_size,
> which is usually true, but not mandated by the spec. (This was added
> inten
On Thu, Jan 08, 2015 at 07:09:22PM +, Ard Biesheuvel wrote:
> On 8 January 2015 at 19:04, Mark Rutland wrote:
> > Hi Ard,
> >
> > On Thu, Jan 08, 2015 at 05:51:47PM +, Ard Biesheuvel wrote:
> >> This fixes two minor issues in the implementation of get_memo
On Fri, Jan 09, 2015 at 10:55:29AM +, Leif Lindholm wrote:
> On Fri, Jan 09, 2015 at 10:19:50AM +0000, Mark Rutland wrote:
> > On Thu, Jan 08, 2015 at 07:09:22PM +, Ard Biesheuvel wrote:
> > > On 8 January 2015 at 19:04, Mark Rutland wrote:
> > > > Hi Ard,
p, we cannot rely on that to be always the
> case, e.g., in the presence of a mem= kernel parameter.
>
> At the same time, remove a stale comment and move the memmap code
> together.
>
> Signed-off-by: Ard Biesheuvel
Acked-by: Mark Rutland
This should probably be picked up befo
On Thu, Feb 12, 2015 at 05:24:19AM +, Ard Biesheuvel wrote:
> As it turns out, when allocating room for the UEFI memory map using
> UEFI's AllocatePool (), it may result in two new memory map entries
> being created, for instance, when using Tianocore's preallocated region
> feature. For exampl
On Thu, Feb 12, 2015 at 10:39:46AM +, Ard Biesheuvel wrote:
> On 12 February 2015 at 18:22, Mark Rutland wrote:
> > On Thu, Feb 12, 2015 at 05:24:19AM +, Ard Biesheuvel wrote:
> >> As it turns out, when allocating room for the UEFI memory map using
> >> UEF
On Thu, Feb 12, 2015 at 02:56:51PM +, Ard Biesheuvel wrote:
> On 12 February 2015 at 22:47, Matt Fleming wrote:
> > On Thu, 12 Feb, at 06:39:46PM, Ard Biesheuvel wrote:
> >>
> >> I don't see how doing a single allocation could result in a single
> >> free region to be split into more than 1 oc
ologies for the hassle.
>
> This is what I've got queued up,
Looks sane to me:
Acked-by: Mark Rutland
Thanks,
Mark.
>
> ---
>
> From 3f281b98ffc99e604a3988aa93304a3a591eeeb5 Mon Sep 17 00:00:00 2001
> From: Matt Fleming
> Date: Fri, 13 Feb 2015 15:46:56 +
>
On Thu, Feb 12, 2015 at 03:31:02PM +, Ard Biesheuvel wrote:
> On 12 February 2015 at 23:16, Mark Rutland wrote:
> > On Thu, Feb 12, 2015 at 02:56:51PM +, Ard Biesheuvel wrote:
> >> On 12 February 2015 at 22:47, Matt Fleming
> >> wrote:
> >>
ytes below 0xc0003000 the current code
> will allocate [0xc0001000-0xc0004000], not [0xc000-0xc0003000]
> like you would expect. - Matt ]
>
> Signed-off-by: Yinghai Lu
> Cc:
I've convinced myself that the new logic is sound, and with this patch
applied atop of v4.0-rc
* ResetSystem().
*/
bool efi_poweroff_required(void)
{
return efi_enabled(EFI_RUNTIME_SERVICES);
}
I've given the patch a spin (with and without that addition) on Juno and
Seattle. So with that folded in:
Tested-by: Mark Rutland
Reviewed-by: Mark Rutland
Thanks,
Mark.
--
eird offsets and large disances from the kernel, and that seems
to work, so:
Reviewed-by: Mark Rutland
Tested-by: Mark Rutland
Thanks,
Mark.
> ---
> Documentation/arm64/booting.txt | 13
> arch/arm64/include/asm/boot.h | 14 +
> arch/arm64/include/asm/fixma
Hi Ard,
On Fri, Jul 24, 2015 at 10:41:53AM +0100, Ard Biesheuvel wrote:
> When allocating memory for the kernel image, try the AllocatePages()
> boot service to obtain memory at the preferred offset of
> 'dram_base + TEXT_OFFSET', and only revert to efi_low_alloc() if that
> fails. This is the onl
On Fri, Jul 24, 2015 at 11:54:47AM +0100, Ard Biesheuvel wrote:
> On 24 July 2015 at 12:49, Mark Rutland wrote:
> > Hi Ard,
> >
> > On Fri, Jul 24, 2015 at 10:41:53AM +0100, Ard Biesheuvel wrote:
> >> When allocating memory for the kernel image, try the AllocatePages
his is the only way to allocate at the base of DRAM if DRAM
> starts at 0x0, since efi_low_alloc() refuses to allocate at 0x0.
>
> Tested-by: Haojian Zhuang
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Mark Rutland
Mark.
> ---
> v2:
> - reshuffle code flow to make it more
Hi,
I'm not necessarily opposed to the renaming, but I think that this is
the least important thing to standardize for this to work.
On Thu, Sep 10, 2015 at 09:41:56AM +0100, Shannon Zhao wrote:
> From: Shannon Zhao
>
> These EFI stub parameters are used to internal communication between EFI
>
> > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI
> > interface?
>
> Xen talks to EFI itself but the interface provided to dom0 is somewhat
> different: there are no BootServices (Xen calls ExitBootServices before
> running the kernel), and the RuntimeServices go via hyperca
On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote:
> On Thu, 10 Sep 2015, Mark Rutland wrote:
> > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI
> > > > interface?
> > >
> > > Xen talks to EFI itself b
Hi,
FWIW I gave this a spin on Seattle and Juno and saw no regressions (both
are pre-2.5 EFI though).
I have some concerns below.
On Wed, Sep 09, 2015 at 08:06:54AM +0100, Ard Biesheuvel wrote:
> The new Properties Table feature introduced in UEFIv2.5 may split
> memory regions that cover PE/COF
> >> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> >> index e8ca6eaedd02..13671a9cf016 100644
> >> --- a/arch/arm64/kernel/efi.c
> >> +++ b/arch/arm64/kernel/efi.c
> >> @@ -258,7 +258,8 @@ static bool __init efi_virtmap_init(void)
> >>*/
> >> if (!is
On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote:
> On Thu, 10 Sep 2015, Mark Rutland wrote:
> > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote:
> > > On Thu, 10 Sep 2015, Mark Rutland wrote:
> > > > > > Does Xen not talk to
On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote:
> >>> On 10.09.15 at 13:37, wrote:
> > On Thu, 10 Sep 2015, Mark Rutland wrote:
> >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g.
> >> create pages of RuntimeServicesCode t
> OK so what we could do is the following:
>
> 8<--
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index e8ca6eaedd02..39fa2a70a7f1 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -233,6 +233,7 @@ void __init efi_init(void)
>
oth 4K and 64K pages.
Both are EFI 2.4, so that only tells us we haven't regressed things.
The code itself looks good to me. Feel free to add:
Reviewed-by: Mark Rutland
Tested-by: Mark Rutland [UEFI 2.4 only]
Thanks,
Mark.
> ---
> Changes since v2:
> - break down complex if() cond
> > C) When you could go:
> >
> >DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI
> > discovery
>
> I take you mean discovering Xen with the usual Xen hypervisor node on
> device tree. I think that C) is a good option actually. I like it. Not
> sure why we didn't think about
On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
> > > > C) When you could go:
> > > >
> > > >DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACP
> It feels like this discussion is going in circles.
>
> When we discussed this six months ago, we already concluded that,
> since UEFI is the only specified way that the presence of ACPI is
> advertised on an ARM system, we need to emulate UEFI to some extent.
My understanding from the last time
> >> Considering that the EFI support is just for Dom0, and Dom0 (at
> >> the time) had to be PV anyway, it was the more natural solution to
> >> expose the interface via hypercalls, the more that this allows better
> >> control over what is and primarily what is not being exposed to
> >> Dom0. Wit
On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
> > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
>
>
Hi Ard,
On Thu, Sep 24, 2015 at 10:46:30PM +0100, Ard Biesheuvel wrote:
> With the stub to kernel interface being promoted to a proper interface
> so that other agents than the stub can boot the kernel proper in EFI
> mode, we can remove the linux,uefi-stub-kern-ver field, considering
> that its o
On Thu, Oct 08, 2015 at 01:36:09PM +0300, Andrey Ryabinin wrote:
> 2015-10-07 13:04 GMT+03:00 Catalin Marinas :
> > On Thu, Sep 17, 2015 at 12:38:06PM +0300, Andrey Ryabinin wrote:
> >> As usual patches available in git
> >> git://github.com/aryabinin/linux.git kasan/arm64v6
> >>
> >> Changes
On Thu, Oct 08, 2015 at 01:36:09PM +0300, Andrey Ryabinin wrote:
> 2015-10-07 13:04 GMT+03:00 Catalin Marinas :
> > On Thu, Sep 17, 2015 at 12:38:06PM +0300, Andrey Ryabinin wrote:
> >> As usual patches available in git
> >> git://github.com/aryabinin/linux.git kasan/arm64v6
> >>
> >> Changes
On Fri, Oct 09, 2015 at 12:32:18PM +0300, Andrey Ryabinin wrote:
[...]
> I thought the EFI stub isolation patches create a copy of mem*() functions in
> the stub,
> but they are just create aliases with __efistub_ prefix.
>
> We only need to create some more aliases for KASAN.
> The following pa
On Fri, Oct 09, 2015 at 01:18:09PM +0300, Andrey Ryabinin wrote:
> 2015-10-09 12:48 GMT+03:00 Mark Rutland :
> > On Fri, Oct 09, 2015 at 12:32:18PM +0300, Andrey Ryabinin wrote:
> > [...]
> >
> >> I thought the EFI stub isolation patches create a copy of mem*
On Tue, Oct 27, 2015 at 09:13:22PM -0500, Timur Tabi wrote:
> Ard Biesheuvel wrote:
> >No. I screwed up the patch since the trailing ) should not be there,
> >but we do need to round first, and only then add the offset.
>
> But if the offset is not a multiple of 2MB, won't the address passed
> to
EFI_PAGE_SIZE;
> > status = efi_call_early(allocate_pages,
> > EFI_ALLOCATE_ADDRESS,
>
> Tested-by: Timur Tabi
> Tested-by: Shanker Donthineni
I assume with the trailing ')' removed. ;)
With that:
Acked-by: Mark Rutland
> Ho
On Wed, Oct 28, 2015 at 01:12:36PM -0500, Timur Tabi wrote:
> On 10/28/2015 01:08 PM, Mark Rutland wrote:
>
> >arm64: efi: ensure kernel is loaded at correct address
> >
> >The kernel image needs to be loaded text_offset_bytes from a 2M-aligned
> >base, per Docum
On Wed, Oct 28, 2015 at 04:02:23PM -0500, Timur Tabi wrote:
> On 10/28/2015 12:26 PM, Mark Rutland wrote:
> >>>This does make the kernel boot, but we suspect that there may be
> >>>another problem. We need to investigate it, but we have a suspicion
> >>>
On Thu, Oct 29, 2015 at 11:59:46AM +0900, Ard Biesheuvel wrote:
> On 29 October 2015 at 03:21, Mark Rutland wrote:
> > On Wed, Oct 28, 2015 at 01:12:36PM -0500, Timur Tabi wrote:
> >> On 10/28/2015 01:08 PM, Mark Rutland wrote:
> >>
> >> >arm64: efi: ens
[Adding Catalin to the To line]
On Fri, Oct 30, 2015 at 01:17:24PM +0100, Ard Biesheuvel wrote:
> On 27 October 2015 at 23:44, Jeremy Linton wrote:
> > On 10/26/2015 09:20 PM, Ard Biesheuvel wrote:
> >>
> >> Thanks for the report. The following patch should fix it
> >
> >
> > Ard,
> >
> > Thanks,
On Tue, Nov 17, 2015 at 12:25:58PM +0100, Ard Biesheuvel wrote:
> On 17 November 2015 at 10:57, wrote:
> > From: Shannon Zhao
> >
> > Add a new function to parse DT parameters for Xen specific UEFI just
> > like the way for normal UEFI. Then it could reuse the existing codes.
> >
> > Signed-off-
>
> Signed-off-by: Ard Biesheuvel
Acked-by: Mark Rutland
Mark.
> ---
> drivers/firmware/efi/libstub/fdt.c | 42
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/fdt.c
> b/drivers/firmware/ef
On Mon, Mar 20, 2017 at 08:57:05PM +, Ard Biesheuvel wrote:
> The EFI stub currently prints a number of diagnostic messages that do
> not carry a lot of information. Since these prints are not controlled
> by 'loglevel' or other command line parameters, and since they appear on
> the EFI frameb
y: Ard Biesheuvel
> ---
> This was previously sent out as a separate patch. The difference is that this
> version looks for 'quiet' rather than 'efi=debug', and preserves the noisy
> console as the default.
This addresses my prior concern, so FWI
[Adding the EFI maintainers]
Tl;DR: Xen's EFI wrappery doesn't implement reset_system, so when
invoked on arm64 we get a NULL dereference.
On Thu, Apr 06, 2017 at 04:39:13PM +0100, Julien Grall wrote:
> On 06/04/17 16:20, Daniel Kiper wrote:
> >On Thu, Apr 06, 2017 at 04:38:24PM +0200, Juergen Gr
On Fri, Apr 07, 2017 at 04:51:16PM +0100, Ard Biesheuvel wrote:
> On 7 April 2017 at 16:47, James Morse wrote:
> > On 24/03/17 13:24, Ard Biesheuvel wrote:
> >> Update the allocation logic for the virtual mapping of the UEFI runtime
> >> services to start from a randomized base address if KASLR is
TASK_SIZE on ARM, both of which
> are compile time constants. Also, change the 'headroom' variable to
> static const to force an error if this changes in the future.
>
> Cc: James Morse
> Cc: Mark Rutland
> Cc: Catalin Marinas
> Cc: Matt Fleming
> Cc: Ingo Molna
Hi Leif,
On Thu, Oct 03, 2013 at 12:24:39PM +0100, Leif Lindholm wrote:
> This patch provides documentation of the [U]EFI runtime services and
> configuration features.
>
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Leif Lindholm
> Acked-by: Rob Landley
> ---
> Documentation/arm/00-INDEX |
Hi Leif,
On Thu, Oct 03, 2013 at 06:18:02PM +0100, Leif Lindholm wrote:
> On Thu, Oct 03, 2013 at 11:11:18AM -0500, Rob Herring wrote:
> > Adding devicetree list since you are defining bindings...
> >
> > > +with CONFIG_OF.
> > > +
> > > +It parses the FDT /chosen node for the following parameter
Hi Leif,
On Fri, Apr 04, 2014 at 07:45:09PM +0100, Leif Lindholm wrote:
> From: Mark Salter
>
> This patch adds PE/COFF header fields to the start of the Image
> so that it appears as an EFI application to EFI firmware. An EFI
> stub is included to allow direct booting of the kernel Image.
> Supp
le at it, fix arm32 as well.
>
> There should be no functional change as a result of this patch.
>
> Signed-off-by: Torsten Duwe
With the indentation removed from the commit text:
Reviewed-by: Mark Rutland
Mark.
>
> ---
> drivers/firmware/efi/libstub/Makefile |
On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote:
> Hi,
>
> I've enabled CONFIG_GCC_PLUGIN_STACKLEAK on 5.2.8 for an arm64
> macchiatobin board and I get the following error when loading the
> kernel (using grub-efi on top of edk ii):
>
> EFI stub: Booting Linux Kernel...
> EFI stub: ERROR:
On Thu, Aug 15, 2019 at 02:21:26PM +0300, Ard Biesheuvel wrote:
> On Thu, 15 Aug 2019 at 14:03, Mark Rutland wrote:
> > On Thu, Aug 15, 2019 at 05:56:27AM -0400, skodde wrote:
> > > Hi,
> > >
> > > I've enabled CONFIG_GCC_PLUGIN_STACKLEAK on 5.2.8 for an
1 - 100 of 113 matches
Mail list logo
