[PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling

[PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling

[Ard Biesheuvel]

Resending this series sent out yesterday with only minor changes and acks etc
added.

In summary: patch #3 relaxes the requirements imposed by the EFI stub on where
Image may be loaded, but this breaks APM Mustang (if booting via UEFI) if patch
#1 does not go in first. Patch #2 prevents potential boot issues when Image is
loaded such that the stub does not have to relocate it.

@Will: as discussed on the list yesterday, these patches should be kept in
sequence when going upstream, so it is best to take them through a single tree.
However, patch #3 will not apply cleanly to the arm64 tree until after 3.16-rc1
is released as it depends on a trivial change going in through x86/tip [efi].
[https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=next&id=6091c9c447370c4717ec9975813c874af490eb36]

If you are ok with these patches, how would you like to proceed? Patches #1 and
#2 could go in straight away (through arm64), and I can send Catalin and you a
gentle reminder once -rc1 is released to take #3? Or instead, ack them and ask
Matt to queue them for 3.17-late? It would be nice if this makes 3.17 as it
fixes actual boot problems on hardware that is under development.

Changes in v2:
- add (__force void *) cast to patch #1, as suggested in LAKML discussion
- add tested-by/acked-by lines
- rebased patch #3 onto efi-next

Mark Rutland (1):
  arm64: spin-table: handle unmapped cpu-release-addrs

Ard Biesheuvel (2):
  arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text
  arm64/efi: efistub: don't abort if base of DRAM is occupied

 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(-)

-- 
1.8.3.2

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

From: Mark Rutland <mark.rutland@arm.com>

In certain cases the cpu-release-addr of a CPU may not fall in the
linear mapping (e.g. when the kernel is loaded above this address due to
the presence of other images in memory). This is problematic for the
spin-table code as it assumes that it can trivially convert a
cpu-release-addr to a valid VA in the linear map.

This patch modifies the spin-table code to use a temporary cached
mapping to write to a given cpu-release-addr, enabling us to support
addresses regardless of whether they are covered by the linear mapping.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Salter <msalter@redhat.com>
[ardb: added (__force void *) cast]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/kernel/smp_spin_table.c b/arch/arm64/kernel/smp_spin_table.c
index 0347d38eea29..4f93c67e63de 100644
--- a/arch/arm64/kernel/smp_spin_table.c
+++ b/arch/arm64/kernel/smp_spin_table.c
@@ -20,6 +20,7 @@
 #include <linux/init.h>
 #include <linux/of.h>
 #include <linux/smp.h>
+#include <linux/types.h>
 
 #include <asm/cacheflush.h>
 #include <asm/cpu_ops.h>
@@ -65,12 +66,21 @@ static int smp_spin_table_cpu_init(struct device_node *dn, unsigned int cpu)
 
 static int smp_spin_table_cpu_prepare(unsigned int cpu)
 {
-	void **release_addr;
+	__le64 __iomem *release_addr;
 
 	if (!cpu_release_addr[cpu])
 		return -ENODEV;
 
-	release_addr = __va(cpu_release_addr[cpu]);
+	/*
+	 * The cpu-release-addr may or may not be inside the linear mapping.
+	 * As ioremap_cache will either give us a new mapping or reuse the
+	 * existing linear mapping, we can use it to cover both cases. In
+	 * either case the memory will be MT_NORMAL.
+	 */
+	release_addr = ioremap_cache(cpu_release_addr[cpu],
+				     sizeof(*release_addr));
+	if (!release_addr)
+		return -ENOMEM;
 
 	/*
 	 * We write the release address as LE regardless of the native
@@ -79,15 +89,17 @@ static int smp_spin_table_cpu_prepare(unsigned int cpu)
 	 * boot-loader's endianess before jumping. This is mandated by
 	 * the boot protocol.
 	 */
-	release_addr[0] = (void *) cpu_to_le64(__pa(secondary_holding_pen));
-
-	__flush_dcache_area(release_addr, sizeof(release_addr[0]));
+	writeq_relaxed(__pa(secondary_holding_pen), release_addr);
+	__flush_dcache_area((__force void *)release_addr,
+			    sizeof(*release_addr));
 
 	/*
 	 * Send an event to wake up the secondary CPU.
 	 */
 	sev();
 
+	iounmap(release_addr);
+
 	return 0;
 }
 
-- 
1.8.3.2

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Will Deacon]

On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
> From: Mark Rutland <mark.rutland@arm.com>
> 
> In certain cases the cpu-release-addr of a CPU may not fall in the
> linear mapping (e.g. when the kernel is loaded above this address due to
> the presence of other images in memory). This is problematic for the
> spin-table code as it assumes that it can trivially convert a
> cpu-release-addr to a valid VA in the linear map.
> 
> This patch modifies the spin-table code to use a temporary cached
> mapping to write to a given cpu-release-addr, enabling us to support
> addresses regardless of whether they are covered by the linear mapping.
> 
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Tested-by: Mark Salter <msalter@redhat.com>
> [ardb: added (__force void *) cast]
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)

I'm nervous about this. What if the spin table sits in the same physical 64k
frame as a read-sensitive device and we're running with 64k pages?

Will

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 30 July 2014 13:30, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
>> From: Mark Rutland <mark.rutland@arm.com>
>>
>> In certain cases the cpu-release-addr of a CPU may not fall in the
>> linear mapping (e.g. when the kernel is loaded above this address due to
>> the presence of other images in memory). This is problematic for the
>> spin-table code as it assumes that it can trivially convert a
>> cpu-release-addr to a valid VA in the linear map.
>>
>> This patch modifies the spin-table code to use a temporary cached
>> mapping to write to a given cpu-release-addr, enabling us to support
>> addresses regardless of whether they are covered by the linear mapping.
>>
>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> Tested-by: Mark Salter <msalter@redhat.com>
>> [ardb: added (__force void *) cast]
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
>>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> I'm nervous about this. What if the spin table sits in the same physical 64k
> frame as a read-sensitive device and we're running with 64k pages?
>

I see what you mean. This is potentially hairy, as EFI already
ioremap_cache()s everything known to it as normal DRAM, so using plain
ioremap() here if pfn_valid() returns false for cpu-release-addr's PFN
may still result in mappings with different attributes for the same
region. So how should we decide whether to call ioremap() or
ioremap_cache() in this case?

-- 
Ard.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 30 July 2014 14:00, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 30 July 2014 13:30, Will Deacon <will.deacon@arm.com> wrote:
>> On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
>>> From: Mark Rutland <mark.rutland@arm.com>
>>>
>>> In certain cases the cpu-release-addr of a CPU may not fall in the
>>> linear mapping (e.g. when the kernel is loaded above this address due to
>>> the presence of other images in memory). This is problematic for the
>>> spin-table code as it assumes that it can trivially convert a
>>> cpu-release-addr to a valid VA in the linear map.
>>>
>>> This patch modifies the spin-table code to use a temporary cached
>>> mapping to write to a given cpu-release-addr, enabling us to support
>>> addresses regardless of whether they are covered by the linear mapping.
>>>
>>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>>> Tested-by: Mark Salter <msalter@redhat.com>
>>> [ardb: added (__force void *) cast]
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> ---
>>>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
>>>  1 file changed, 17 insertions(+), 5 deletions(-)
>>
>> I'm nervous about this. What if the spin table sits in the same physical 64k
>> frame as a read-sensitive device and we're running with 64k pages?
>>
>
> I see what you mean. This is potentially hairy, as EFI already
> ioremap_cache()s everything known to it as normal DRAM, so using plain

Clarification: every Runtime Services region known to it as being
normal DRAM, which may cover this area

> ioremap() here if pfn_valid() returns false for cpu-release-addr's PFN
> may still result in mappings with different attributes for the same
> region. So how should we decide whether to call ioremap() or
> ioremap_cache() in this case?
>
> --
> Ard.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Mark Rutland]

On Wed, Jul 30, 2014 at 01:00:40PM +0100, Ard Biesheuvel wrote:
> On 30 July 2014 13:30, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
> >> From: Mark Rutland <mark.rutland@arm.com>
> >>
> >> In certain cases the cpu-release-addr of a CPU may not fall in the
> >> linear mapping (e.g. when the kernel is loaded above this address due to
> >> the presence of other images in memory). This is problematic for the
> >> spin-table code as it assumes that it can trivially convert a
> >> cpu-release-addr to a valid VA in the linear map.
> >>
> >> This patch modifies the spin-table code to use a temporary cached
> >> mapping to write to a given cpu-release-addr, enabling us to support
> >> addresses regardless of whether they are covered by the linear mapping.
> >>
> >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> >> Tested-by: Mark Salter <msalter@redhat.com>
> >> [ardb: added (__force void *) cast]
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> ---
> >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
> >>  1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > I'm nervous about this. What if the spin table sits in the same physical 64k
> > frame as a read-sensitive device and we're running with 64k pages?
> >
> 
> I see what you mean. This is potentially hairy, as EFI already
> ioremap_cache()s everything known to it as normal DRAM, so using plain
> ioremap() here if pfn_valid() returns false for cpu-release-addr's PFN
> may still result in mappings with different attributes for the same
> region. So how should we decide whether to call ioremap() or
> ioremap_cache() in this case?

If we're careful about handling mismatched attributes we might be able
to get away with always using a device mapping.

I'll need to have a think about that, I'm not sure on the architected
cache behaviour in such a case.

Thanks,
Mark.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Will Deacon]

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 <will.deacon@arm.com> wrote:
> > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
> > >> From: Mark Rutland <mark.rutland@arm.com>
> > >>
> > >> In certain cases the cpu-release-addr of a CPU may not fall in the
> > >> linear mapping (e.g. when the kernel is loaded above this address due to
> > >> the presence of other images in memory). This is problematic for the
> > >> spin-table code as it assumes that it can trivially convert a
> > >> cpu-release-addr to a valid VA in the linear map.
> > >>
> > >> This patch modifies the spin-table code to use a temporary cached
> > >> mapping to write to a given cpu-release-addr, enabling us to support
> > >> addresses regardless of whether they are covered by the linear mapping.
> > >>
> > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > >> Tested-by: Mark Salter <msalter@redhat.com>
> > >> [ardb: added (__force void *) cast]
> > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > >> ---
> > >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
> > >>  1 file changed, 17 insertions(+), 5 deletions(-)
> > >
> > > I'm nervous about this. What if the spin table sits in the same physical 64k
> > > frame as a read-sensitive device and we're running with 64k pages?
> > >
> > 
> > I see what you mean. This is potentially hairy, as EFI already
> > ioremap_cache()s everything known to it as normal DRAM, so using plain
> > ioremap() here if pfn_valid() returns false for cpu-release-addr's PFN
> > may still result in mappings with different attributes for the same
> > region. So how should we decide whether to call ioremap() or
> > ioremap_cache() in this case?
> 
> If we're careful about handling mismatched attributes we might be able
> to get away with always using a device mapping.

Even then, I think ioremap hits a WARN_ON if pfn_valid.

> I'll need to have a think about that, I'm not sure on the architected
> cache behaviour in such a case.

Of we just skip the cache flush if !pfn_valid.

Will

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Mark Rutland]

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 <will.deacon@arm.com> wrote:
> > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
> > > >> From: Mark Rutland <mark.rutland@arm.com>
> > > >>
> > > >> In certain cases the cpu-release-addr of a CPU may not fall in the
> > > >> linear mapping (e.g. when the kernel is loaded above this address due to
> > > >> the presence of other images in memory). This is problematic for the
> > > >> spin-table code as it assumes that it can trivially convert a
> > > >> cpu-release-addr to a valid VA in the linear map.
> > > >>
> > > >> This patch modifies the spin-table code to use a temporary cached
> > > >> mapping to write to a given cpu-release-addr, enabling us to support
> > > >> addresses regardless of whether they are covered by the linear mapping.
> > > >>
> > > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > >> Tested-by: Mark Salter <msalter@redhat.com>
> > > >> [ardb: added (__force void *) cast]
> > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > >> ---
> > > >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
> > > >>  1 file changed, 17 insertions(+), 5 deletions(-)
> > > >
> > > > I'm nervous about this. What if the spin table sits in the same physical 64k
> > > > frame as a read-sensitive device and we're running with 64k pages?
> > > >
> > > 
> > > I see what you mean. This is potentially hairy, as EFI already
> > > ioremap_cache()s everything known to it as normal DRAM, so using plain
> > > ioremap() here if pfn_valid() returns false for cpu-release-addr's PFN
> > > may still result in mappings with different attributes for the same
> > > region. So how should we decide whether to call ioremap() or
> > > ioremap_cache() in this case?
> > 
> > If we're careful about handling mismatched attributes we might be able
> > to get away with always using a device mapping.
> 
> Even then, I think ioremap hits a WARN_ON if pfn_valid.

Ok, that's that idea dead then.

> > I'll need to have a think about that, I'm not sure on the architected
> > cache behaviour in such a case.
> 
> Of we just skip the cache flush if !pfn_valid.

I don't think that's always safe given Ard's comment that the EFI code
will possibly have a mapping covering the region created by
ioremap_cache.

Ard, what exactly does the EFI code map with ioremap_cache, and why?

Cheers,
Mark.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 30 July 2014 14:49, Mark Rutland <mark.rutland@arm.com> wrote:
> 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 <will.deacon@arm.com> wrote:
>> > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
>> > > >> From: Mark Rutland <mark.rutland@arm.com>
>> > > >>
>> > > >> In certain cases the cpu-release-addr of a CPU may not fall in the
>> > > >> linear mapping (e.g. when the kernel is loaded above this address due to
>> > > >> the presence of other images in memory). This is problematic for the
>> > > >> spin-table code as it assumes that it can trivially convert a
>> > > >> cpu-release-addr to a valid VA in the linear map.
>> > > >>
>> > > >> This patch modifies the spin-table code to use a temporary cached
>> > > >> mapping to write to a given cpu-release-addr, enabling us to support
>> > > >> addresses regardless of whether they are covered by the linear mapping.
>> > > >>
>> > > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> > > >> Tested-by: Mark Salter <msalter@redhat.com>
>> > > >> [ardb: added (__force void *) cast]
>> > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> > > >> ---
>> > > >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
>> > > >>  1 file changed, 17 insertions(+), 5 deletions(-)
>> > > >
>> > > > I'm nervous about this. What if the spin table sits in the same physical 64k
>> > > > frame as a read-sensitive device and we're running with 64k pages?
>> > > >
>> > >
>> > > I see what you mean. This is potentially hairy, as EFI already
>> > > ioremap_cache()s everything known to it as normal DRAM, so using plain
>> > > ioremap() here if pfn_valid() returns false for cpu-release-addr's PFN
>> > > may still result in mappings with different attributes for the same
>> > > region. So how should we decide whether to call ioremap() or
>> > > ioremap_cache() in this case?
>> >
>> > If we're careful about handling mismatched attributes we might be able
>> > to get away with always using a device mapping.
>>
>> Even then, I think ioremap hits a WARN_ON if pfn_valid.
>
> Ok, that's that idea dead then.
>
>> > I'll need to have a think about that, I'm not sure on the architected
>> > cache behaviour in such a case.
>>
>> Of we just skip the cache flush if !pfn_valid.
>
> I don't think that's always safe given Ard's comment that the EFI code
> will possibly have a mapping covering the region created by
> ioremap_cache.
>
> Ard, what exactly does the EFI code map with ioremap_cache, and why?
>

Actually, after re-reading the spec and the code, perhaps this is not an issue.
The EFI __init code calls ioremap_cache() for all regions described by
the UEFI memory map as requiring a virtual mapping
(EFI_MEMORY_RUNTIME): this is primarily runtime services code and data
regions and perhaps some I/O mappings for flash or other peripherals
that UEFI owns and needs to access during Runtime Services calls.

Mark Salter mentioned that APM Mustang's spin table lives in an
EFI_RESERVED_TYPE region, which presumably would not have the
EFI_MEMORY_RUNTIME attribute set, as it has nothing to do with the
UEFI Runtime Services. This means that no cached mapping should
already exist for that region.

-- 
Ard.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 30 July 2014 15:10, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 30 July 2014 14:49, Mark Rutland <mark.rutland@arm.com> wrote:
>> 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 <will.deacon@arm.com> wrote:
>>> > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
>>> > > >> From: Mark Rutland <mark.rutland@arm.com>
>>> > > >>
>>> > > >> In certain cases the cpu-release-addr of a CPU may not fall in the
>>> > > >> linear mapping (e.g. when the kernel is loaded above this address due to
>>> > > >> the presence of other images in memory). This is problematic for the
>>> > > >> spin-table code as it assumes that it can trivially convert a
>>> > > >> cpu-release-addr to a valid VA in the linear map.
>>> > > >>
>>> > > >> This patch modifies the spin-table code to use a temporary cached
>>> > > >> mapping to write to a given cpu-release-addr, enabling us to support
>>> > > >> addresses regardless of whether they are covered by the linear mapping.
>>> > > >>
>>> > > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>>> > > >> Tested-by: Mark Salter <msalter@redhat.com>
>>> > > >> [ardb: added (__force void *) cast]
>>> > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> > > >> ---
>>> > > >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
>>> > > >>  1 file changed, 17 insertions(+), 5 deletions(-)
>>> > > >
>>> > > > I'm nervous about this. What if the spin table sits in the same physical 64k
>>> > > > frame as a read-sensitive device and we're running with 64k pages?
>>> > > >
>>> > >
>>> > > I see what you mean. This is potentially hairy, as EFI already
>>> > > ioremap_cache()s everything known to it as normal DRAM, so using plain
>>> > > ioremap() here if pfn_valid() returns false for cpu-release-addr's PFN
>>> > > may still result in mappings with different attributes for the same
>>> > > region. So how should we decide whether to call ioremap() or
>>> > > ioremap_cache() in this case?
>>> >
>>> > If we're careful about handling mismatched attributes we might be able
>>> > to get away with always using a device mapping.
>>>
>>> Even then, I think ioremap hits a WARN_ON if pfn_valid.
>>
>> Ok, that's that idea dead then.
>>
>>> > I'll need to have a think about that, I'm not sure on the architected
>>> > cache behaviour in such a case.
>>>
>>> Of we just skip the cache flush if !pfn_valid.
>>
>> I don't think that's always safe given Ard's comment that the EFI code
>> will possibly have a mapping covering the region created by
>> ioremap_cache.
>>
>> Ard, what exactly does the EFI code map with ioremap_cache, and why?
>>
>
> Actually, after re-reading the spec and the code, perhaps this is not an issue.
> The EFI __init code calls ioremap_cache() for all regions described by
> the UEFI memory map as requiring a virtual mapping
> (EFI_MEMORY_RUNTIME): this is primarily runtime services code and data
> regions and perhaps some I/O mappings for flash or other peripherals
> that UEFI owns and needs to access during Runtime Services calls.
>
> Mark Salter mentioned that APM Mustang's spin table lives in an
> EFI_RESERVED_TYPE region, which presumably would not have the
> EFI_MEMORY_RUNTIME attribute set, as it has nothing to do with the
> UEFI Runtime Services. This means that no cached mapping should
> already exist for that region.
>

That said, there is another potential snag: the UEFI spec for AArch64
does not allow regions residing in the same 64k phys frame to have
different memory attributes, and in order to meet this requirement, an
EFI_RESERVED_TYPE region could supposedly still be described with a
EFI_MEMORY_WB (cacheable) attribute set (e.g. if it shares the 64k
phys frame with Runtime Services Code or Data)

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

]On 30 July 2014 13:30, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
>> From: Mark Rutland <mark.rutland@arm.com>
>>
>> In certain cases the cpu-release-addr of a CPU may not fall in the
>> linear mapping (e.g. when the kernel is loaded above this address due to
>> the presence of other images in memory). This is problematic for the
>> spin-table code as it assumes that it can trivially convert a
>> cpu-release-addr to a valid VA in the linear map.
>>
>> This patch modifies the spin-table code to use a temporary cached
>> mapping to write to a given cpu-release-addr, enabling us to support
>> addresses regardless of whether they are covered by the linear mapping.
>>
>> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> Tested-by: Mark Salter <msalter@redhat.com>
>> [ardb: added (__force void *) cast]
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
>>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> I'm nervous about this. What if the spin table sits in the same physical 64k
> frame as a read-sensitive device and we're running with 64k pages?
>

Actually, booting.txt requires cpu-release-addr to point to a
/memreserve/d part of memory, which implies DRAM (or you wouldn't have
to memreserve it)
That means it should always be covered by the linear mapping, unless
it is located before Image in DRAM, which is the case addressed by
this patch.

-- 
Ard.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Will Deacon]

On Wed, Jul 30, 2014 at 08:17:02PM +0100, Ard Biesheuvel wrote:
> ]On 30 July 2014 13:30, Will Deacon <will.deacon@arm.com> wrote:
> > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
> >> From: Mark Rutland <mark.rutland@arm.com>
> >>
> >> In certain cases the cpu-release-addr of a CPU may not fall in the
> >> linear mapping (e.g. when the kernel is loaded above this address due to
> >> the presence of other images in memory). This is problematic for the
> >> spin-table code as it assumes that it can trivially convert a
> >> cpu-release-addr to a valid VA in the linear map.
> >>
> >> This patch modifies the spin-table code to use a temporary cached
> >> mapping to write to a given cpu-release-addr, enabling us to support
> >> addresses regardless of whether they are covered by the linear mapping.
> >>
> >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> >> Tested-by: Mark Salter <msalter@redhat.com>
> >> [ardb: added (__force void *) cast]
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> ---
> >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
> >>  1 file changed, 17 insertions(+), 5 deletions(-)
> >
> > I'm nervous about this. What if the spin table sits in the same physical 64k
> > frame as a read-sensitive device and we're running with 64k pages?
> >
> 
> Actually, booting.txt requires cpu-release-addr to point to a
> /memreserve/d part of memory, which implies DRAM (or you wouldn't have
> to memreserve it)
> That means it should always be covered by the linear mapping, unless
> it is located before Image in DRAM, which is the case addressed by
> this patch.

But if it's located before before the Image in DRAM and isn't covered by
the linear mapping, then surely the /memreserve/ is pointless too? In which
case, this looks like we're simply trying to cater for platforms that aren't
following booting.txt (which may need updating if we need to handle this).

Will

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Mark Rutland]

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 <will.deacon@arm.com> wrote:
> > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
> > >> From: Mark Rutland <mark.rutland@arm.com>
> > >>
> > >> In certain cases the cpu-release-addr of a CPU may not fall in the
> > >> linear mapping (e.g. when the kernel is loaded above this address due to
> > >> the presence of other images in memory). This is problematic for the
> > >> spin-table code as it assumes that it can trivially convert a
> > >> cpu-release-addr to a valid VA in the linear map.
> > >>
> > >> This patch modifies the spin-table code to use a temporary cached
> > >> mapping to write to a given cpu-release-addr, enabling us to support
> > >> addresses regardless of whether they are covered by the linear mapping.
> > >>
> > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > >> Tested-by: Mark Salter <msalter@redhat.com>
> > >> [ardb: added (__force void *) cast]
> > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > >> ---
> > >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
> > >>  1 file changed, 17 insertions(+), 5 deletions(-)
> > >
> > > I'm nervous about this. What if the spin table sits in the same physical 64k
> > > frame as a read-sensitive device and we're running with 64k pages?
> > >
> > 
> > Actually, booting.txt requires cpu-release-addr to point to a
> > /memreserve/d part of memory, which implies DRAM (or you wouldn't have
> > to memreserve it)
> > That means it should always be covered by the linear mapping, unless
> > it is located before Image in DRAM, which is the case addressed by
> > this patch.
> 
> But if it's located before before the Image in DRAM and isn't covered by
> the linear mapping, then surely the /memreserve/ is pointless too? In which
> case, this looks like we're simply trying to cater for platforms that aren't
> following booting.txt (which may need updating if we need to handle this).

No. The DT is describing the memory which is present, and the subset
thereof which should not be used under normal circumstances. That's a
static property of the system.

Where the OS happens to get loaded and what it is able to address is a
dynamic property of the OS (and possibly the bootloader). The DT cannot
have knowledge of this.

It's always true that the OS should not blindly use memreserve'd memory.
The fact that it cannot address it in the linear mapping is orthogonal.

Cheers,
Mark.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Will Deacon]

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:
> > > ]On 30 July 2014 13:30, Will Deacon <will.deacon@arm.com> wrote:
> > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
> > > >> From: Mark Rutland <mark.rutland@arm.com>
> > > >>
> > > >> In certain cases the cpu-release-addr of a CPU may not fall in the
> > > >> linear mapping (e.g. when the kernel is loaded above this address due to
> > > >> the presence of other images in memory). This is problematic for the
> > > >> spin-table code as it assumes that it can trivially convert a
> > > >> cpu-release-addr to a valid VA in the linear map.
> > > >>
> > > >> This patch modifies the spin-table code to use a temporary cached
> > > >> mapping to write to a given cpu-release-addr, enabling us to support
> > > >> addresses regardless of whether they are covered by the linear mapping.
> > > >>
> > > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > >> Tested-by: Mark Salter <msalter@redhat.com>
> > > >> [ardb: added (__force void *) cast]
> > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > >> ---
> > > >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
> > > >>  1 file changed, 17 insertions(+), 5 deletions(-)
> > > >
> > > > I'm nervous about this. What if the spin table sits in the same physical 64k
> > > > frame as a read-sensitive device and we're running with 64k pages?
> > > >
> > > 
> > > Actually, booting.txt requires cpu-release-addr to point to a
> > > /memreserve/d part of memory, which implies DRAM (or you wouldn't have
> > > to memreserve it)
> > > That means it should always be covered by the linear mapping, unless
> > > it is located before Image in DRAM, which is the case addressed by
> > > this patch.
> > 
> > But if it's located before before the Image in DRAM and isn't covered by
> > the linear mapping, then surely the /memreserve/ is pointless too? In which
> > case, this looks like we're simply trying to cater for platforms that aren't
> > following booting.txt (which may need updating if we need to handle this).
> 
> No. The DT is describing the memory which is present, and the subset
> thereof which should not be used under normal circumstances. That's a
> static property of the system.
> 
> Where the OS happens to get loaded and what it is able to address is a
> dynamic property of the OS (and possibly the bootloader). The DT cannot
> have knowledge of this.
> 
> It's always true that the OS should not blindly use memreserve'd memory.
> The fact that it cannot address it in the linear mapping is orthogonal.

In which case, I think asserting that /memreserve/ implies DRAM is pretty
fragile and not actually enforced anywhere. Sure, we can say `don't do
that', but I'd prefer to have the kernel detect this dynamically.

Does dtc check that the /memreserve/ region is actually a subset of the
memory node?

Will

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 31 July 2014 12:04, Will Deacon <will.deacon@arm.com> 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:
>> > > ]On 30 July 2014 13:30, Will Deacon <will.deacon@arm.com> wrote:
>> > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
>> > > >> From: Mark Rutland <mark.rutland@arm.com>
>> > > >>
>> > > >> In certain cases the cpu-release-addr of a CPU may not fall in the
>> > > >> linear mapping (e.g. when the kernel is loaded above this address due to
>> > > >> the presence of other images in memory). This is problematic for the
>> > > >> spin-table code as it assumes that it can trivially convert a
>> > > >> cpu-release-addr to a valid VA in the linear map.
>> > > >>
>> > > >> This patch modifies the spin-table code to use a temporary cached
>> > > >> mapping to write to a given cpu-release-addr, enabling us to support
>> > > >> addresses regardless of whether they are covered by the linear mapping.
>> > > >>
>> > > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> > > >> Tested-by: Mark Salter <msalter@redhat.com>
>> > > >> [ardb: added (__force void *) cast]
>> > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> > > >> ---
>> > > >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
>> > > >>  1 file changed, 17 insertions(+), 5 deletions(-)
>> > > >
>> > > > I'm nervous about this. What if the spin table sits in the same physical 64k
>> > > > frame as a read-sensitive device and we're running with 64k pages?
>> > > >
>> > >
>> > > Actually, booting.txt requires cpu-release-addr to point to a
>> > > /memreserve/d part of memory, which implies DRAM (or you wouldn't have
>> > > to memreserve it)
>> > > That means it should always be covered by the linear mapping, unless
>> > > it is located before Image in DRAM, which is the case addressed by
>> > > this patch.
>> >
>> > But if it's located before before the Image in DRAM and isn't covered by
>> > the linear mapping, then surely the /memreserve/ is pointless too? In which
>> > case, this looks like we're simply trying to cater for platforms that aren't
>> > following booting.txt (which may need updating if we need to handle this).
>>
>> No. The DT is describing the memory which is present, and the subset
>> thereof which should not be used under normal circumstances. That's a
>> static property of the system.
>>
>> Where the OS happens to get loaded and what it is able to address is a
>> dynamic property of the OS (and possibly the bootloader). The DT cannot
>> have knowledge of this.
>>
>> It's always true that the OS should not blindly use memreserve'd memory.
>> The fact that it cannot address it in the linear mapping is orthogonal.
>
> In which case, I think asserting that /memreserve/ implies DRAM is pretty
> fragile and not actually enforced anywhere. Sure, we can say `don't do
> that', but I'd prefer to have the kernel detect this dynamically.
>

The point is whether we can assume that cpu-release-addr always
resides in DRAM, not whether /memreserve/ implies DRAM. The former
should be the case for all current implementations, because we only
ever access it through the linear mapping.

This means that rather than worrying about all the corner cases where
cpu-release-addr may share its 64k physical frame with device
registers etc, couldn't we just update booting.txt to state that
cpu-release-addr should be chosen such that it can be mapped with a
64k granule MT_NORMAL mapping?

-- 
Ard.



> Does dtc check that the /memreserve/ region is actually a subset of the
> memory node?
>
> Will

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Mark Rutland]

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:
> > > > ]On 30 July 2014 13:30, Will Deacon <will.deacon@arm.com> wrote:
> > > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
> > > > >> From: Mark Rutland <mark.rutland@arm.com>
> > > > >>
> > > > >> In certain cases the cpu-release-addr of a CPU may not fall in the
> > > > >> linear mapping (e.g. when the kernel is loaded above this address due to
> > > > >> the presence of other images in memory). This is problematic for the
> > > > >> spin-table code as it assumes that it can trivially convert a
> > > > >> cpu-release-addr to a valid VA in the linear map.
> > > > >>
> > > > >> This patch modifies the spin-table code to use a temporary cached
> > > > >> mapping to write to a given cpu-release-addr, enabling us to support
> > > > >> addresses regardless of whether they are covered by the linear mapping.
> > > > >>
> > > > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > > >> Tested-by: Mark Salter <msalter@redhat.com>
> > > > >> [ardb: added (__force void *) cast]
> > > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > > >> ---
> > > > >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
> > > > >>  1 file changed, 17 insertions(+), 5 deletions(-)
> > > > >
> > > > > I'm nervous about this. What if the spin table sits in the same physical 64k
> > > > > frame as a read-sensitive device and we're running with 64k pages?
> > > > >
> > > > 
> > > > Actually, booting.txt requires cpu-release-addr to point to a
> > > > /memreserve/d part of memory, which implies DRAM (or you wouldn't have
> > > > to memreserve it)
> > > > That means it should always be covered by the linear mapping, unless
> > > > it is located before Image in DRAM, which is the case addressed by
> > > > this patch.
> > > 
> > > But if it's located before before the Image in DRAM and isn't covered by
> > > the linear mapping, then surely the /memreserve/ is pointless too? In which
> > > case, this looks like we're simply trying to cater for platforms that aren't
> > > following booting.txt (which may need updating if we need to handle this).
> > 
> > No. The DT is describing the memory which is present, and the subset
> > thereof which should not be used under normal circumstances. That's a
> > static property of the system.
> > 
> > Where the OS happens to get loaded and what it is able to address is a
> > dynamic property of the OS (and possibly the bootloader). The DT cannot
> > have knowledge of this.
> > 
> > It's always true that the OS should not blindly use memreserve'd memory.
> > The fact that it cannot address it in the linear mapping is orthogonal.
> 
> In which case, I think asserting that /memreserve/ implies DRAM is pretty
> fragile and not actually enforced anywhere. Sure, we can say `don't do
> that', but I'd prefer to have the kernel detect this dynamically.

I think the boot protocol needs an update to allow a cpu-release-addr
not covered by linear mapping. There are reasons that the kernel might
not be loaded at the start of RAM, and I think relying on the
cpu-release-addr addresses lying in the linear mapping is a limitation
we need to address. Given that I also think we should allow for
cpu-release-addrs outside of the range desribed by memory nodes (and
therefore not requiring any /mremreserve/).

I do not think we should rely on being able to address the
cpu-release-addr with a normal cacheable mapping. If the
cpu-release-addr falls outside of the memory described by the memory
node(s) then we have no idea where it lives. Currently this falls in
normal memory, but mandating that feels odd.

The sole purpose of /memreserve/ is to describe areas in physical memory
that memory should not be used for general allocation. I don't think it
makes any sense to derive any information from /memreserve/ other than
the fact said addresses shouldn't be poked arbitarily. If we allow
cpu-release-addrs outside of memory, then we won't have a /memreserve/
anyhow.

So the question becomes can or can't we always detect when we already
have a mapping that covers a cpu-release-addr?

> Does dtc check that the /memreserve/ region is actually a subset of the
> memory node?

I don't beleive it does. It's probably a sensible warning, but as far as
I am aware the only time the memory reservation table will be read in
any OS is to poke holes in its memory allocation pool(s).

Cheers,
Mark.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 31 July 2014 12:39, Mark Rutland <mark.rutland@arm.com> wrote:
> 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:
>> > > > ]On 30 July 2014 13:30, Will Deacon <will.deacon@arm.com> wrote:
>> > > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
>> > > > >> From: Mark Rutland <mark.rutland@arm.com>
>> > > > >>
>> > > > >> In certain cases the cpu-release-addr of a CPU may not fall in the
>> > > > >> linear mapping (e.g. when the kernel is loaded above this address due to
>> > > > >> the presence of other images in memory). This is problematic for the
>> > > > >> spin-table code as it assumes that it can trivially convert a
>> > > > >> cpu-release-addr to a valid VA in the linear map.
>> > > > >>
>> > > > >> This patch modifies the spin-table code to use a temporary cached
>> > > > >> mapping to write to a given cpu-release-addr, enabling us to support
>> > > > >> addresses regardless of whether they are covered by the linear mapping.
>> > > > >>
>> > > > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> > > > >> Tested-by: Mark Salter <msalter@redhat.com>
>> > > > >> [ardb: added (__force void *) cast]
>> > > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> > > > >> ---
>> > > > >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
>> > > > >>  1 file changed, 17 insertions(+), 5 deletions(-)
>> > > > >
>> > > > > I'm nervous about this. What if the spin table sits in the same physical 64k
>> > > > > frame as a read-sensitive device and we're running with 64k pages?
>> > > > >
>> > > >
>> > > > Actually, booting.txt requires cpu-release-addr to point to a
>> > > > /memreserve/d part of memory, which implies DRAM (or you wouldn't have
>> > > > to memreserve it)
>> > > > That means it should always be covered by the linear mapping, unless
>> > > > it is located before Image in DRAM, which is the case addressed by
>> > > > this patch.
>> > >
>> > > But if it's located before before the Image in DRAM and isn't covered by
>> > > the linear mapping, then surely the /memreserve/ is pointless too? In which
>> > > case, this looks like we're simply trying to cater for platforms that aren't
>> > > following booting.txt (which may need updating if we need to handle this).
>> >
>> > No. The DT is describing the memory which is present, and the subset
>> > thereof which should not be used under normal circumstances. That's a
>> > static property of the system.
>> >
>> > Where the OS happens to get loaded and what it is able to address is a
>> > dynamic property of the OS (and possibly the bootloader). The DT cannot
>> > have knowledge of this.
>> >
>> > It's always true that the OS should not blindly use memreserve'd memory.
>> > The fact that it cannot address it in the linear mapping is orthogonal.
>>
>> In which case, I think asserting that /memreserve/ implies DRAM is pretty
>> fragile and not actually enforced anywhere. Sure, we can say `don't do
>> that', but I'd prefer to have the kernel detect this dynamically.
>
> I think the boot protocol needs an update to allow a cpu-release-addr
> not covered by linear mapping. There are reasons that the kernel might
> not be loaded at the start of RAM, and I think relying on the
> cpu-release-addr addresses lying in the linear mapping is a limitation
> we need to address. Given that I also think we should allow for
> cpu-release-addrs outside of the range desribed by memory nodes (and
> therefore not requiring any /mremreserve/).
>

While I agree that it would be a nice thing to get that requirement
relaxed, do we necessarily need to address both issues at once?

In a sense, this patch is a bug fix: even if a platform fully adheres
to booting.txt, by putting the cpu-release-addr in a memreserved part
of DRAM and loading Image at a 2 meg offset + TEXT_OFFSET, SMP will be
broken in some cases, and that needs to be fixed. This issue is not
imaginary, as TEXT_OFFSET fuzzing may well result in boot failures on
APM Mustang, and the fix for /that/ (loading at the next 2 meg
boundary (+ TEXT_OFFSET) up, a thing which booting.txt specifically
allows) triggers the issue that this patch addresses.

> I do not think we should rely on being able to address the
> cpu-release-addr with a normal cacheable mapping. If the
> cpu-release-addr falls outside of the memory described by the memory
> node(s) then we have no idea where it lives. Currently this falls in
> normal memory, but mandating that feels odd.
>

We have the luxury that all existing working implementations have
cpu-release-addr inside the linear mapping (or SMP would already be
broken). Why makes our lives complicated by allowing things that
nobody has asked for yet? Including dedicated SRAM patches makes
sense, since anything that can tolerate being mapped MT_NORMAL using
64k granule can be supported with your current code, but beyond that,
what is the use case?

> The sole purpose of /memreserve/ is to describe areas in physical memory
> that memory should not be used for general allocation. I don't think it
> makes any sense to derive any information from /memreserve/ other than
> the fact said addresses shouldn't be poked arbitarily. If we allow
> cpu-release-addrs outside of memory, then we won't have a /memreserve/
> anyhow.
>
> So the question becomes can or can't we always detect when we already
> have a mapping that covers a cpu-release-addr?
>

Let's not get ourselves into this mess.

>> Does dtc check that the /memreserve/ region is actually a subset of the
>> memory node?
>
> I don't beleive it does. It's probably a sensible warning, but as far as
> I am aware the only time the memory reservation table will be read in
> any OS is to poke holes in its memory allocation pool(s).
>
> Cheers,
> Mark.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Mark Salter]

On Thu, 2014-07-31 at 11:04 +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:
> > > > ]On 30 July 2014 13:30, Will Deacon <will.deacon@arm.com> wrote:
> > > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
> > > > >> From: Mark Rutland <mark.rutland@arm.com>
> > > > >>
> > > > >> In certain cases the cpu-release-addr of a CPU may not fall in the
> > > > >> linear mapping (e.g. when the kernel is loaded above this address due to
> > > > >> the presence of other images in memory). This is problematic for the
> > > > >> spin-table code as it assumes that it can trivially convert a
> > > > >> cpu-release-addr to a valid VA in the linear map.
> > > > >>
> > > > >> This patch modifies the spin-table code to use a temporary cached
> > > > >> mapping to write to a given cpu-release-addr, enabling us to support
> > > > >> addresses regardless of whether they are covered by the linear mapping.
> > > > >>
> > > > >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > > >> Tested-by: Mark Salter <msalter@redhat.com>
> > > > >> [ardb: added (__force void *) cast]
> > > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > > > >> ---
> > > > >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
> > > > >>  1 file changed, 17 insertions(+), 5 deletions(-)
> > > > >
> > > > > I'm nervous about this. What if the spin table sits in the same physical 64k
> > > > > frame as a read-sensitive device and we're running with 64k pages?
> > > > >
> > > > 
> > > > Actually, booting.txt requires cpu-release-addr to point to a
> > > > /memreserve/d part of memory, which implies DRAM (or you wouldn't have
> > > > to memreserve it)
> > > > That means it should always be covered by the linear mapping, unless
> > > > it is located before Image in DRAM, which is the case addressed by
> > > > this patch.
> > > 
> > > But if it's located before before the Image in DRAM and isn't covered by
> > > the linear mapping, then surely the /memreserve/ is pointless too? In which
> > > case, this looks like we're simply trying to cater for platforms that aren't
> > > following booting.txt (which may need updating if we need to handle this).
> > 
> > No. The DT is describing the memory which is present, and the subset
> > thereof which should not be used under normal circumstances. That's a
> > static property of the system.
> > 
> > Where the OS happens to get loaded and what it is able to address is a
> > dynamic property of the OS (and possibly the bootloader). The DT cannot
> > have knowledge of this.
> > 
> > It's always true that the OS should not blindly use memreserve'd memory.
> > The fact that it cannot address it in the linear mapping is orthogonal.
> 
> In which case, I think asserting that /memreserve/ implies DRAM is pretty
> fragile and not actually enforced anywhere. Sure, we can say `don't do
> that', but I'd prefer to have the kernel detect this dynamically.
> 
> Does dtc check that the /memreserve/ region is actually a subset of the
> memory node?

The handling of /memreserve/ in drivers/of/fdt.c uses the memblock API
to reserve. And that means it is assumed that /memreserve/ is something
which can be covered by the normal kernel RAM mapping. I suspect having
/memreserve/ outside the kernel mapping would cause problems for the mm
code.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 31 July 2014 11:45, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Jul 30, 2014 at 08:17:02PM +0100, Ard Biesheuvel wrote:
>> ]On 30 July 2014 13:30, Will Deacon <will.deacon@arm.com> wrote:
>> > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
>> >> From: Mark Rutland <mark.rutland@arm.com>
>> >>
>> >> In certain cases the cpu-release-addr of a CPU may not fall in the
>> >> linear mapping (e.g. when the kernel is loaded above this address due to
>> >> the presence of other images in memory). This is problematic for the
>> >> spin-table code as it assumes that it can trivially convert a
>> >> cpu-release-addr to a valid VA in the linear map.
>> >>
>> >> This patch modifies the spin-table code to use a temporary cached
>> >> mapping to write to a given cpu-release-addr, enabling us to support
>> >> addresses regardless of whether they are covered by the linear mapping.
>> >>
>> >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
>> >> Tested-by: Mark Salter <msalter@redhat.com>
>> >> [ardb: added (__force void *) cast]
>> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> >> ---
>> >>  arch/arm64/kernel/smp_spin_table.c | 22 +++++++++++++++++-----
>> >>  1 file changed, 17 insertions(+), 5 deletions(-)
>> >
>> > I'm nervous about this. What if the spin table sits in the same physical 64k
>> > frame as a read-sensitive device and we're running with 64k pages?
>> >
>>
>> Actually, booting.txt requires cpu-release-addr to point to a
>> /memreserve/d part of memory, which implies DRAM (or you wouldn't have
>> to memreserve it)
>> That means it should always be covered by the linear mapping, unless
>> it is located before Image in DRAM, which is the case addressed by
>> this patch.
>
> But if it's located before before the Image in DRAM and isn't covered by
> the linear mapping, then surely the /memreserve/ is pointless too? In which

No, it isn't. The existence of a linear mapping and where exactly it
starts is an implementation detail of arm64 linux, whereas marking
some regions of DRAM as containing firmware bits that should be left
alone by the OS has a purpose in general. Also, with TEXT_OFFSET
likely being changed in the future, the start of the linear mapping
may change as well.

> case, this looks like we're simply trying to cater for platforms that aren't
> following booting.txt (which may need updating if we need to handle this).
>

booting.txt is not clear about the purpose of TEXT_OFFSET or whether
the area below it should be kept vacant. So APM Mustang, for instance,
keeps their holding pen there, which is entirely legal by the current
wording of booting.txt. And it is memreserve'd, so the linear mapping
will cover it but the memory will not be touched other than to bring
up the secondaries.

The point I was trying to make is that booting.txt seems to suggest
(but it should be clarified) that cpu-release-addr must always reside
on DRAM, in which case it is highly unlikely that some peripheral mem
region with I/O semantics shares its 64k page frame.

-- 
Ard.

[PATCH v2 2/3] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text

[Ard Biesheuvel]

The static memory footprint of a kernel Image at boot is larger than the
Image file itself. Things like .bss data and initial page tables are allocated
statically but populated dynamically so their content is not contained in the
Image file.

However, if EFI (or GRUB) has loaded the Image at precisely the desired offset
of base of DRAM + TEXT_OFFSET, the Image will be booted in place, and we have
to make sure that the allocation done by the PE/COFF loader is large enough.

Fix this by growing the PE/COFF .text section to cover the entire static
memory footprint. The part of the section that is not covered by the payload
will be zero initialised by the PE/COFF loader.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Mark Salter <msalter@redhat.com>
---
 arch/arm64/kernel/head.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 144f10567f82..b6ca95aee348 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -151,7 +151,7 @@ optional_header:
 	.short	0x20b				// PE32+ format
 	.byte	0x02				// MajorLinkerVersion
 	.byte	0x14				// MinorLinkerVersion
-	.long	_edata - stext			// SizeOfCode
+	.long	_end - stext			// SizeOfCode
 	.long	0				// SizeOfInitializedData
 	.long	0				// SizeOfUninitializedData
 	.long	efi_stub_entry - efi_head	// AddressOfEntryPoint
@@ -169,7 +169,7 @@ extra_header_fields:
 	.short	0				// MinorSubsystemVersion
 	.long	0				// Win32VersionValue
 
-	.long	_edata - efi_head		// SizeOfImage
+	.long	_end - efi_head			// SizeOfImage
 
 	// Everything before the kernel image is considered part of the header
 	.long	stext - efi_head		// SizeOfHeaders
@@ -216,7 +216,7 @@ section_table:
 	.byte	0
 	.byte	0
 	.byte	0        		// end of 0 padding of section name
-	.long	_edata - stext		// VirtualSize
+	.long	_end - stext		// VirtualSize
 	.long	stext - efi_head	// VirtualAddress
 	.long	_edata - stext		// SizeOfRawData
 	.long	stext - efi_head	// PointerToRawData
-- 
1.8.3.2

[PATCH v2 2/3] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text

[Mark Rutland]

On Wed, Jul 30, 2014 at 11:59:03AM +0100, Ard Biesheuvel wrote:
> The static memory footprint of a kernel Image at boot is larger than the
> Image file itself. Things like .bss data and initial page tables are allocated
> statically but populated dynamically so their content is not contained in the
> Image file.
> 
> However, if EFI (or GRUB) has loaded the Image at precisely the desired offset
> of base of DRAM + TEXT_OFFSET, the Image will be booted in place, and we have
> to make sure that the allocation done by the PE/COFF loader is large enough.
> 
> Fix this by growing the PE/COFF .text section to cover the entire static
> memory footprint. The part of the section that is not covered by the payload
> will be zero initialised by the PE/COFF loader.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Acked-by: Mark Salter <msalter@redhat.com>

This looks sane to 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 <mark.rutland@arm.com>

> ---
>  arch/arm64/kernel/head.S | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 144f10567f82..b6ca95aee348 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -151,7 +151,7 @@ optional_header:
>  	.short	0x20b				// PE32+ format
>  	.byte	0x02				// MajorLinkerVersion
>  	.byte	0x14				// MinorLinkerVersion
> -	.long	_edata - stext			// SizeOfCode
> +	.long	_end - stext			// SizeOfCode
>  	.long	0				// SizeOfInitializedData
>  	.long	0				// SizeOfUninitializedData
>  	.long	efi_stub_entry - efi_head	// AddressOfEntryPoint
> @@ -169,7 +169,7 @@ extra_header_fields:
>  	.short	0				// MinorSubsystemVersion
>  	.long	0				// Win32VersionValue
>  
> -	.long	_edata - efi_head		// SizeOfImage
> +	.long	_end - efi_head			// SizeOfImage
>  
>  	// Everything before the kernel image is considered part of the header
>  	.long	stext - efi_head		// SizeOfHeaders
> @@ -216,7 +216,7 @@ section_table:
>  	.byte	0
>  	.byte	0
>  	.byte	0        		// end of 0 padding of section name
> -	.long	_edata - stext		// VirtualSize
> +	.long	_end - stext		// VirtualSize
>  	.long	stext - efi_head	// VirtualAddress
>  	.long	_edata - stext		// SizeOfRawData
>  	.long	stext - efi_head	// PointerToRawData
> -- 
> 1.8.3.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo at 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

[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.biesheuvel@linaro.org>
Acked-by: Mark Salter <msalter@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

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

[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.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
> 
> 

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

[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.biesheuvel@linaro.org>
> > Acked-by: Mark Salter <msalter@redhat.com>
> 
> Acked-by: Mark Rutland <mark.rutland@arm.com>

Ard, who's picking this up?

-- 
Matt Fleming, Intel Open Source Technology Center

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

[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.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

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

[Ard Biesheuvel]

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(-)

-- 
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=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

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

[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

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

[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+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.

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

[Will Deacon]

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

[PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling

[Leif Lindholm]

On Wed, Jul 30, 2014 at 12:59:01PM +0200, Ard Biesheuvel wrote:
> Resending this series sent out yesterday with only minor changes and acks etc
> added.
> 
> In summary: patch #3 relaxes the requirements imposed by the EFI stub on where
> Image may be loaded, but this breaks APM Mustang (if booting via UEFI) if patch
> #1 does not go in first. Patch #2 prevents potential boot issues when Image is
> loaded such that the stub does not have to relocate it.
> 
> @Will: as discussed on the list yesterday, these patches should be kept in
> sequence when going upstream, so it is best to take them through a single tree.
> However, patch #3 will not apply cleanly to the arm64 tree until after 3.16-rc1
> is released as it depends on a trivial change going in through x86/tip [efi].
> [https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/commit/?h=next&id=6091c9c447370c4717ec9975813c874af490eb36]
> 
> If you are ok with these patches, how would you like to proceed? Patches #1 and
> #2 could go in straight away (through arm64), and I can send Catalin and you a
> gentle reminder once -rc1 is released to take #3? Or instead, ack them and ask
> Matt to queue them for 3.17-late? It would be nice if this makes 3.17 as it
> fixes actual boot problems on hardware that is under development.
> 
> Changes in v2:
> - add (__force void *) cast to patch #1, as suggested in LAKML discussion
> - add tested-by/acked-by lines
> - rebased patch #3 onto efi-next
> 
> Mark Rutland (1):
>   arm64: spin-table: handle unmapped cpu-release-addrs
> 
> Ard Biesheuvel (2):
>   arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text
>   arm64/efi: efistub: don't abort if base of DRAM is occupied
> 
>  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(-)
> 
> -- 
> 1.8.3.2

Since this set fixes two separate bugs on actual hardware platforms,
for the entire set - for what it's worth:
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Tested-by: Leif Lindholm <leif.lindholm@linaro.org>

/
    Leif

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Mark Rutland]

Hi Ard,

> Gents,
> 
> With the 3.17 merge window not far from closing, is there anything we
> could still do this cycle to get $subject addressed?
> As I have indicated before, the newly introduced TEXT_OFFSET fuzzing
> may break APM Mustang if booting from UEFI (i.e., for low values of
> rand()), and as this option is recommended for distribution kernels,
> it could make apt-get update'ing your kernel a frustrating experience.
> However, the fix for that issue triggers the issue addressed by
> $subject.
> 
> In my personal opinion, relaxing the requirements imposed on where
> your cpu-release-addr may live could remain a separate discussion. In
> the APM Mustang case, even when adhering to booting.txt by the letter
> (i.e., pu cpu-release-addr in a memreserved area in DRAM and load
> Image at a 2 meg boundary + TEXT_OFFSET), the kernel fails to bring up
> the secondaries if the cpu-release-addr is below the kernel.

For the moment I would be happy with the patch as it stands (using
ioremap_cache).

Catalin, Will?

Mark.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Catalin Marinas]

On Wed, Aug 13, 2014 at 01:58:45PM +0100, Mark Rutland wrote:
> > With the 3.17 merge window not far from closing, is there anything we
> > could still do this cycle to get $subject addressed?
> > As I have indicated before, the newly introduced TEXT_OFFSET fuzzing
> > may break APM Mustang if booting from UEFI (i.e., for low values of
> > rand()), and as this option is recommended for distribution kernels,
> > it could make apt-get update'ing your kernel a frustrating experience.
> > However, the fix for that issue triggers the issue addressed by
> > $subject.
> > 
> > In my personal opinion, relaxing the requirements imposed on where
> > your cpu-release-addr may live could remain a separate discussion. In
> > the APM Mustang case, even when adhering to booting.txt by the letter
> > (i.e., pu cpu-release-addr in a memreserved area in DRAM and load
> > Image at a 2 meg boundary + TEXT_OFFSET), the kernel fails to bring up
> > the secondaries if the cpu-release-addr is below the kernel.
> 
> For the moment I would be happy with the patch as it stands (using
> ioremap_cache).
> 
> Catalin, Will?

Using ioremap_cache() sounds fine to me but I have to dig the original
patches as I've only been cc'ed in the middle of the thread (and that's
just for patch 1/3).

-- 
Catalin

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 14 August 2014 19:13, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Wed, Aug 13, 2014 at 01:58:45PM +0100, Mark Rutland wrote:
>> > With the 3.17 merge window not far from closing, is there anything we
>> > could still do this cycle to get $subject addressed?
>> > As I have indicated before, the newly introduced TEXT_OFFSET fuzzing
>> > may break APM Mustang if booting from UEFI (i.e., for low values of
>> > rand()), and as this option is recommended for distribution kernels,
>> > it could make apt-get update'ing your kernel a frustrating experience.
>> > However, the fix for that issue triggers the issue addressed by
>> > $subject.
>> >
>> > In my personal opinion, relaxing the requirements imposed on where
>> > your cpu-release-addr may live could remain a separate discussion. In
>> > the APM Mustang case, even when adhering to booting.txt by the letter
>> > (i.e., pu cpu-release-addr in a memreserved area in DRAM and load
>> > Image at a 2 meg boundary + TEXT_OFFSET), the kernel fails to bring up
>> > the secondaries if the cpu-release-addr is below the kernel.
>>
>> For the moment I would be happy with the patch as it stands (using
>> ioremap_cache).
>>
>> Catalin, Will?
>
> Using ioremap_cache() sounds fine to me but I have to dig the original
> patches as I've only been cc'ed in the middle of the thread (and that's
> just for patch 1/3).
>

http://marc.info/?l=linux-arm-kernel&m=140671806332258&w=2
http://marc.info/?l=linux-arm-kernel&m=140671807532262&w=2
http://marc.info/?l=linux-arm-kernel&m=140671807732263&w=2

Patch 3/3 makes the EFI stub load Image at the lowest 2 meg boundary +
TEXT_OFFSET instead of erroring out when base of DRAM + TEXT_OFFSET is
occupied. This is necessary as the randomized TEXT_OFFSET could
potentially conflict with reserved areas at the base of DRAM if a low
value happens to be chosen.

Patch 1/3 fixes the resulting breakage on APM Mustang in bringing up
the secondaries, as on that board in particular, the reserved area at
the base of DRAM contains the holding pen, and loading Image higher up
makes the mailbox inaccessible through the linear mapping hence the
need for ioremap_cache()

Patch 2/3 is also a fix for a potential issue on UEFI boot, but it is
unrelated to 1/3 and 3/3

-- 
Ard.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Will Deacon]

On Thu, Aug 14, 2014 at 07:10:13PM +0100, Ard Biesheuvel wrote:
> On 14 August 2014 19:13, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Wed, Aug 13, 2014 at 01:58:45PM +0100, Mark Rutland wrote:
> >> > With the 3.17 merge window not far from closing, is there anything we
> >> > could still do this cycle to get $subject addressed?
> >> > As I have indicated before, the newly introduced TEXT_OFFSET fuzzing
> >> > may break APM Mustang if booting from UEFI (i.e., for low values of
> >> > rand()), and as this option is recommended for distribution kernels,
> >> > it could make apt-get update'ing your kernel a frustrating experience.
> >> > However, the fix for that issue triggers the issue addressed by
> >> > $subject.
> >> >
> >> > In my personal opinion, relaxing the requirements imposed on where
> >> > your cpu-release-addr may live could remain a separate discussion. In
> >> > the APM Mustang case, even when adhering to booting.txt by the letter
> >> > (i.e., pu cpu-release-addr in a memreserved area in DRAM and load
> >> > Image at a 2 meg boundary + TEXT_OFFSET), the kernel fails to bring up
> >> > the secondaries if the cpu-release-addr is below the kernel.
> >>
> >> For the moment I would be happy with the patch as it stands (using
> >> ioremap_cache).
> >>
> >> Catalin, Will?
> >
> > Using ioremap_cache() sounds fine to me but I have to dig the original
> > patches as I've only been cc'ed in the middle of the thread (and that's
> > just for patch 1/3).
> >
> 
> http://marc.info/?l=linux-arm-kernel&m=140671806332258&w=2
> http://marc.info/?l=linux-arm-kernel&m=140671807532262&w=2
> http://marc.info/?l=linux-arm-kernel&m=140671807732263&w=2
> 
> Patch 3/3 makes the EFI stub load Image at the lowest 2 meg boundary +
> TEXT_OFFSET instead of erroring out when base of DRAM + TEXT_OFFSET is
> occupied. This is necessary as the randomized TEXT_OFFSET could
> potentially conflict with reserved areas at the base of DRAM if a low
> value happens to be chosen.
> 
> Patch 1/3 fixes the resulting breakage on APM Mustang in bringing up
> the secondaries, as on that board in particular, the reserved area at
> the base of DRAM contains the holding pen, and loading Image higher up
> makes the mailbox inaccessible through the linear mapping hence the
> need for ioremap_cache()
> 
> Patch 2/3 is also a fix for a potential issue on UEFI boot, but it is
> unrelated to 1/3 and 3/3

I was planning to take all of these for 3.18 as there's no regression here
(the fuzzing is a new debug feature and defaults to `n'). Do you think these
qualify as -rc1 material?

Will

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 15 August 2014 13:57, Will Deacon <will.deacon@arm.com> wrote:
> On Thu, Aug 14, 2014 at 07:10:13PM +0100, Ard Biesheuvel wrote:
>> On 14 August 2014 19:13, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> > On Wed, Aug 13, 2014 at 01:58:45PM +0100, Mark Rutland wrote:
>> >> > With the 3.17 merge window not far from closing, is there anything we
>> >> > could still do this cycle to get $subject addressed?
>> >> > As I have indicated before, the newly introduced TEXT_OFFSET fuzzing
>> >> > may break APM Mustang if booting from UEFI (i.e., for low values of
>> >> > rand()), and as this option is recommended for distribution kernels,
>> >> > it could make apt-get update'ing your kernel a frustrating experience.
>> >> > However, the fix for that issue triggers the issue addressed by
>> >> > $subject.
>> >> >
>> >> > In my personal opinion, relaxing the requirements imposed on where
>> >> > your cpu-release-addr may live could remain a separate discussion. In
>> >> > the APM Mustang case, even when adhering to booting.txt by the letter
>> >> > (i.e., pu cpu-release-addr in a memreserved area in DRAM and load
>> >> > Image at a 2 meg boundary + TEXT_OFFSET), the kernel fails to bring up
>> >> > the secondaries if the cpu-release-addr is below the kernel.
>> >>
>> >> For the moment I would be happy with the patch as it stands (using
>> >> ioremap_cache).
>> >>
>> >> Catalin, Will?
>> >
>> > Using ioremap_cache() sounds fine to me but I have to dig the original
>> > patches as I've only been cc'ed in the middle of the thread (and that's
>> > just for patch 1/3).
>> >
>>
>> http://marc.info/?l=linux-arm-kernel&m=140671806332258&w=2
>> http://marc.info/?l=linux-arm-kernel&m=140671807532262&w=2
>> http://marc.info/?l=linux-arm-kernel&m=140671807732263&w=2
>>
>> Patch 3/3 makes the EFI stub load Image at the lowest 2 meg boundary +
>> TEXT_OFFSET instead of erroring out when base of DRAM + TEXT_OFFSET is
>> occupied. This is necessary as the randomized TEXT_OFFSET could
>> potentially conflict with reserved areas at the base of DRAM if a low
>> value happens to be chosen.
>>
>> Patch 1/3 fixes the resulting breakage on APM Mustang in bringing up
>> the secondaries, as on that board in particular, the reserved area at
>> the base of DRAM contains the holding pen, and loading Image higher up
>> makes the mailbox inaccessible through the linear mapping hence the
>> need for ioremap_cache()
>>
>> Patch 2/3 is also a fix for a potential issue on UEFI boot, but it is
>> unrelated to 1/3 and 3/3
>
> I was planning to take all of these for 3.18 as there's no regression here
> (the fuzzing is a new debug feature and defaults to `n'). Do you think these
> qualify as -rc1 material?
>

Considering that TEXT_OFFSET fuzzing is recommended to be turned on
for distro kernels, I would say this is definitely appropriate for
3.17

-- 
Ard.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Will Deacon]

On Fri, Aug 15, 2014 at 01:07:16PM +0100, Ard Biesheuvel wrote:
> On 15 August 2014 13:57, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Aug 14, 2014 at 07:10:13PM +0100, Ard Biesheuvel wrote:
> >> Patch 3/3 makes the EFI stub load Image at the lowest 2 meg boundary +
> >> TEXT_OFFSET instead of erroring out when base of DRAM + TEXT_OFFSET is
> >> occupied. This is necessary as the randomized TEXT_OFFSET could
> >> potentially conflict with reserved areas at the base of DRAM if a low
> >> value happens to be chosen.
> >>
> >> Patch 1/3 fixes the resulting breakage on APM Mustang in bringing up
> >> the secondaries, as on that board in particular, the reserved area at
> >> the base of DRAM contains the holding pen, and loading Image higher up
> >> makes the mailbox inaccessible through the linear mapping hence the
> >> need for ioremap_cache()
> >>
> >> Patch 2/3 is also a fix for a potential issue on UEFI boot, but it is
> >> unrelated to 1/3 and 3/3
> >
> > I was planning to take all of these for 3.18 as there's no regression here
> > (the fuzzing is a new debug feature and defaults to `n'). Do you think these
> > qualify as -rc1 material?
> >
> 
> Considering that TEXT_OFFSET fuzzing is recommended to be turned on
> for distro kernels, I would say this is definitely appropriate for
> 3.17

Whilst I see that in the commit log, the same recommendation doesn't appear
in the Kconfig text and I'm not sure that it's such a wise thing to say
either. From a distribution's point of view, I think I'd want any kernel
issues to be as reproducible as possible, and fuzzing the text offset seems
to go against that.

Will

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 15 August 2014 14:53, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Aug 15, 2014 at 01:07:16PM +0100, Ard Biesheuvel wrote:
>> On 15 August 2014 13:57, Will Deacon <will.deacon@arm.com> wrote:
>> > On Thu, Aug 14, 2014 at 07:10:13PM +0100, Ard Biesheuvel wrote:
>> >> Patch 3/3 makes the EFI stub load Image at the lowest 2 meg boundary +
>> >> TEXT_OFFSET instead of erroring out when base of DRAM + TEXT_OFFSET is
>> >> occupied. This is necessary as the randomized TEXT_OFFSET could
>> >> potentially conflict with reserved areas at the base of DRAM if a low
>> >> value happens to be chosen.
>> >>
>> >> Patch 1/3 fixes the resulting breakage on APM Mustang in bringing up
>> >> the secondaries, as on that board in particular, the reserved area at
>> >> the base of DRAM contains the holding pen, and loading Image higher up
>> >> makes the mailbox inaccessible through the linear mapping hence the
>> >> need for ioremap_cache()
>> >>
>> >> Patch 2/3 is also a fix for a potential issue on UEFI boot, but it is
>> >> unrelated to 1/3 and 3/3
>> >
>> > I was planning to take all of these for 3.18 as there's no regression here
>> > (the fuzzing is a new debug feature and defaults to `n'). Do you think these
>> > qualify as -rc1 material?
>> >
>>
>> Considering that TEXT_OFFSET fuzzing is recommended to be turned on
>> for distro kernels, I would say this is definitely appropriate for
>> 3.17
>
> Whilst I see that in the commit log, the same recommendation doesn't appear
> in the Kconfig text and I'm not sure that it's such a wise thing to say
> either. From a distribution's point of view, I think I'd want any kernel
> issues to be as reproducible as possible, and fuzzing the text offset seems
> to go against that.
>

OK. There is one other real world issue that 3/3 addresses, which are
platforms that have memreserves at the base of DRAM containing bits of
UEFI itself (this is what got this whole discussion going in the first
place). Currently, we cannot boot via UEFI on these platforms, as the
EFI stub will only consider base of DRAM + TEXT_OFFSET as an option,
and fail the boot if it is not available.

If this is something that could wait until 3.18 as well (Mark S?),
then it's fine by me.

-- 
Ard

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Mark Salter]

On Fri, 2014-08-15 at 15:28 +0200, Ard Biesheuvel wrote:
> On 15 August 2014 14:53, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Aug 15, 2014 at 01:07:16PM +0100, Ard Biesheuvel wrote:
> >> On 15 August 2014 13:57, Will Deacon <will.deacon@arm.com> wrote:
> >> > On Thu, Aug 14, 2014 at 07:10:13PM +0100, Ard Biesheuvel wrote:
> >> >> Patch 3/3 makes the EFI stub load Image at the lowest 2 meg boundary +
> >> >> TEXT_OFFSET instead of erroring out when base of DRAM + TEXT_OFFSET is
> >> >> occupied. This is necessary as the randomized TEXT_OFFSET could
> >> >> potentially conflict with reserved areas at the base of DRAM if a low
> >> >> value happens to be chosen.
> >> >>
> >> >> Patch 1/3 fixes the resulting breakage on APM Mustang in bringing up
> >> >> the secondaries, as on that board in particular, the reserved area at
> >> >> the base of DRAM contains the holding pen, and loading Image higher up
> >> >> makes the mailbox inaccessible through the linear mapping hence the
> >> >> need for ioremap_cache()
> >> >>
> >> >> Patch 2/3 is also a fix for a potential issue on UEFI boot, but it is
> >> >> unrelated to 1/3 and 3/3
> >> >
> >> > I was planning to take all of these for 3.18 as there's no regression here
> >> > (the fuzzing is a new debug feature and defaults to `n'). Do you think these
> >> > qualify as -rc1 material?
> >> >
> >>
> >> Considering that TEXT_OFFSET fuzzing is recommended to be turned on
> >> for distro kernels, I would say this is definitely appropriate for
> >> 3.17
> >
> > Whilst I see that in the commit log, the same recommendation doesn't appear
> > in the Kconfig text and I'm not sure that it's such a wise thing to say
> > either. From a distribution's point of view, I think I'd want any kernel
> > issues to be as reproducible as possible, and fuzzing the text offset seems
> > to go against that.
> >
> 
> OK. There is one other real world issue that 3/3 addresses, which are
> platforms that have memreserves at the base of DRAM containing bits of
> UEFI itself (this is what got this whole discussion going in the first
> place). Currently, we cannot boot via UEFI on these platforms, as the
> EFI stub will only consider base of DRAM + TEXT_OFFSET as an option,
> and fail the boot if it is not available.
> 
> If this is something that could wait until 3.18 as well (Mark S?),
> then it's fine by me.
> 

I don't see a problem with waiting until 3.18.

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Will Deacon]

On Fri, Aug 15, 2014 at 03:35:55PM +0100, Mark Salter wrote:
> On Fri, 2014-08-15 at 15:28 +0200, Ard Biesheuvel wrote:
> > On 15 August 2014 14:53, Will Deacon <will.deacon@arm.com> wrote:
> > > On Fri, Aug 15, 2014 at 01:07:16PM +0100, Ard Biesheuvel wrote:
> > >> On 15 August 2014 13:57, Will Deacon <will.deacon@arm.com> wrote:
> > >> > I was planning to take all of these for 3.18 as there's no regression here
> > >> > (the fuzzing is a new debug feature and defaults to `n'). Do you think these
> > >> > qualify as -rc1 material?
> > >> >
> > >>
> > >> Considering that TEXT_OFFSET fuzzing is recommended to be turned on
> > >> for distro kernels, I would say this is definitely appropriate for
> > >> 3.17
> > >
> > > Whilst I see that in the commit log, the same recommendation doesn't appear
> > > in the Kconfig text and I'm not sure that it's such a wise thing to say
> > > either. From a distribution's point of view, I think I'd want any kernel
> > > issues to be as reproducible as possible, and fuzzing the text offset seems
> > > to go against that.
> > >
> > 
> > OK. There is one other real world issue that 3/3 addresses, which are
> > platforms that have memreserves at the base of DRAM containing bits of
> > UEFI itself (this is what got this whole discussion going in the first
> > place). Currently, we cannot boot via UEFI on these platforms, as the
> > EFI stub will only consider base of DRAM + TEXT_OFFSET as an option,
> > and fail the boot if it is not available.
> > 
> > If this is something that could wait until 3.18 as well (Mark S?),
> > then it's fine by me.
> > 
> 
> I don't see a problem with waiting until 3.18.

Cheers, I've applied the series to our for-next branch and I'll push
everything out at -rc1.

Will

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Leif Lindholm]

On Fri, Aug 15, 2014 at 03:38:04PM +0100, Will Deacon wrote:
> On Fri, Aug 15, 2014 at 03:35:55PM +0100, Mark Salter wrote:
> > On Fri, 2014-08-15 at 15:28 +0200, Ard Biesheuvel wrote:
> > > On 15 August 2014 14:53, Will Deacon <will.deacon@arm.com> wrote:
> > > > On Fri, Aug 15, 2014 at 01:07:16PM +0100, Ard Biesheuvel wrote:
> > > >> On 15 August 2014 13:57, Will Deacon <will.deacon@arm.com> wrote:
> > > >> > I was planning to take all of these for 3.18 as there's no regression here
> > > >> > (the fuzzing is a new debug feature and defaults to `n'). Do you think these
> > > >> > qualify as -rc1 material?
> > > >> >
> > > >>
> > > >> Considering that TEXT_OFFSET fuzzing is recommended to be turned on
> > > >> for distro kernels, I would say this is definitely appropriate for
> > > >> 3.17
> > > >
> > > > Whilst I see that in the commit log, the same recommendation doesn't appear
> > > > in the Kconfig text and I'm not sure that it's such a wise thing to say
> > > > either. From a distribution's point of view, I think I'd want any kernel
> > > > issues to be as reproducible as possible, and fuzzing the text offset seems
> > > > to go against that.
> > > 
> > > OK. There is one other real world issue that 3/3 addresses, which are
> > > platforms that have memreserves at the base of DRAM containing bits of
> > > UEFI itself (this is what got this whole discussion going in the first
> > > place). Currently, we cannot boot via UEFI on these platforms, as the
> > > EFI stub will only consider base of DRAM + TEXT_OFFSET as an option,
> > > and fail the boot if it is not available.
> > > 
> > > If this is something that could wait until 3.18 as well (Mark S?),
> > > then it's fine by me.
> > 
> > I don't see a problem with waiting until 3.18.
> 
> Cheers, I've applied the series to our for-next branch and I'll push
> everything out at -rc1.

Late to the discussion since I was on an 11h flight, and still chiming
in since I don't think previous speakers were explicit enough about
the implication:
Bumping 3/3 to 3.18 means the upstream kernel will not boot on AMD
Seattle until at least December. This sounds suboptimal to me.

/
    Leif

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Catalin Marinas]

On Sun, Aug 17, 2014 at 01:06:09AM +0100, Leif Lindholm wrote:
> On Fri, Aug 15, 2014 at 03:38:04PM +0100, Will Deacon wrote:
> > On Fri, Aug 15, 2014 at 03:35:55PM +0100, Mark Salter wrote:
> > > On Fri, 2014-08-15 at 15:28 +0200, Ard Biesheuvel wrote:
> > > > On 15 August 2014 14:53, Will Deacon <will.deacon@arm.com> wrote:
> > > > > On Fri, Aug 15, 2014 at 01:07:16PM +0100, Ard Biesheuvel wrote:
> > > > >> On 15 August 2014 13:57, Will Deacon <will.deacon@arm.com> wrote:
> > > > >> > I was planning to take all of these for 3.18 as there's no regression here
> > > > >> > (the fuzzing is a new debug feature and defaults to `n'). Do you think these
> > > > >> > qualify as -rc1 material?
> > > > >>
> > > > >> Considering that TEXT_OFFSET fuzzing is recommended to be turned on
> > > > >> for distro kernels, I would say this is definitely appropriate for
> > > > >> 3.17
> > > > >
> > > > > Whilst I see that in the commit log, the same recommendation doesn't appear
> > > > > in the Kconfig text and I'm not sure that it's such a wise thing to say
> > > > > either. From a distribution's point of view, I think I'd want any kernel
> > > > > issues to be as reproducible as possible, and fuzzing the text offset seems
> > > > > to go against that.
> > > > 
> > > > OK. There is one other real world issue that 3/3 addresses, which are
> > > > platforms that have memreserves at the base of DRAM containing bits of
> > > > UEFI itself (this is what got this whole discussion going in the first
> > > > place). Currently, we cannot boot via UEFI on these platforms, as the
> > > > EFI stub will only consider base of DRAM + TEXT_OFFSET as an option,
> > > > and fail the boot if it is not available.
> > > > 
> > > > If this is something that could wait until 3.18 as well (Mark S?),
> > > > then it's fine by me.
> > > 
> > > I don't see a problem with waiting until 3.18.
> > 
> > Cheers, I've applied the series to our for-next branch and I'll push
> > everything out at -rc1.
> 
> Late to the discussion since I was on an 11h flight, and still chiming
> in since I don't think previous speakers were explicit enough about
> the implication:
> Bumping 3/3 to 3.18 means the upstream kernel will not boot on AMD
> Seattle until at least December. This sounds suboptimal to me.

Not unless they use PSCI. That's already working (the spin-table is
meant for platforms where PSCI cannot be implemented).

BTW, is Seattle officially supported by the mainline kernel (it was
barely announced AFAICT)?

-- 
Catalin

[PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs

[Ard Biesheuvel]

On 18 August 2014 18:47, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Sun, Aug 17, 2014 at 01:06:09AM +0100, Leif Lindholm wrote:
>> On Fri, Aug 15, 2014 at 03:38:04PM +0100, Will Deacon wrote:
>> > On Fri, Aug 15, 2014 at 03:35:55PM +0100, Mark Salter wrote:
>> > > On Fri, 2014-08-15 at 15:28 +0200, Ard Biesheuvel wrote:
>> > > > On 15 August 2014 14:53, Will Deacon <will.deacon@arm.com> wrote:
>> > > > > On Fri, Aug 15, 2014 at 01:07:16PM +0100, Ard Biesheuvel wrote:
>> > > > >> On 15 August 2014 13:57, Will Deacon <will.deacon@arm.com> wrote:
>> > > > >> > I was planning to take all of these for 3.18 as there's no regression here
>> > > > >> > (the fuzzing is a new debug feature and defaults to `n'). Do you think these
>> > > > >> > qualify as -rc1 material?
>> > > > >>
>> > > > >> Considering that TEXT_OFFSET fuzzing is recommended to be turned on
>> > > > >> for distro kernels, I would say this is definitely appropriate for
>> > > > >> 3.17
>> > > > >
>> > > > > Whilst I see that in the commit log, the same recommendation doesn't appear
>> > > > > in the Kconfig text and I'm not sure that it's such a wise thing to say
>> > > > > either. From a distribution's point of view, I think I'd want any kernel
>> > > > > issues to be as reproducible as possible, and fuzzing the text offset seems
>> > > > > to go against that.
>> > > >
>> > > > OK. There is one other real world issue that 3/3 addresses, which are
>> > > > platforms that have memreserves at the base of DRAM containing bits of
>> > > > UEFI itself (this is what got this whole discussion going in the first
>> > > > place). Currently, we cannot boot via UEFI on these platforms, as the
>> > > > EFI stub will only consider base of DRAM + TEXT_OFFSET as an option,
>> > > > and fail the boot if it is not available.
>> > > >
>> > > > If this is something that could wait until 3.18 as well (Mark S?),
>> > > > then it's fine by me.
>> > >
>> > > I don't see a problem with waiting until 3.18.
>> >
>> > Cheers, I've applied the series to our for-next branch and I'll push
>> > everything out at -rc1.
>>
>> Late to the discussion since I was on an 11h flight, and still chiming
>> in since I don't think previous speakers were explicit enough about
>> the implication:
>> Bumping 3/3 to 3.18 means the upstream kernel will not boot on AMD
>> Seattle until at least December. This sounds suboptimal to me.
>
> Not unless they use PSCI. That's already working (the spin-table is
> meant for platforms where PSCI cannot be implemented).
>

No, that is patch #1

#3 allows other base addresses than base of DRAM + TEXT_OFFSET when
booting via UEFI, which is needed by AMD Seattle.
However, #3 breaks booting the secondaries on APM Mustang, hence #1.

-- 
Ard.


> BTW, is Seattle officially supported by the mainline kernel (it was
> barely announced AFAICT)?
>
> --
> Catalin