* [PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling @ 2014-07-30 10:59 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 10:59 UTC (permalink / raw) To: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, mark.rutland-5wv7dgnIgG8, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8 Cc: matt.fleming-ral2JQCrhuEAvxtiuMwx3w, 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling @ 2014-07-30 10:59 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 10:59 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <1406717944-24725-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-30 10:59 ` Ard Biesheuvel @ 2014-07-30 10:59 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 10:59 UTC (permalink / raw) To: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, mark.rutland-5wv7dgnIgG8, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8 Cc: matt.fleming-ral2JQCrhuEAvxtiuMwx3w, Ard Biesheuvel From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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-5wv7dgnIgG8@public.gmane.org> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> [ardb: added (__force void *) cast] Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-30 10:59 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 10:59 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
[parent not found: <1406717944-24725-2-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-30 10:59 ` Ard Biesheuvel @ 2014-07-30 11:30 ` Will Deacon -1 siblings, 0 replies; 72+ messages in thread From: Will Deacon @ 2014-07-30 11:30 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: > From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> > > 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-5wv7dgnIgG8@public.gmane.org> > Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > [ardb: added (__force void *) cast] > Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-30 11:30 ` Will Deacon 0 siblings, 0 replies; 72+ messages in thread From: Will Deacon @ 2014-07-30 11:30 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <20140730113013.GL12239-5wv7dgnIgG8@public.gmane.org>]
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-30 11:30 ` Will Deacon @ 2014-07-30 12:00 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 12:00 UTC (permalink / raw) To: Will Deacon Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w On 30 July 2014 13:30, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote: > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> >> >> 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-5wv7dgnIgG8@public.gmane.org> >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> [ardb: added (__force void *) cast] >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-30 12:00 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 12:00 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <CAKv+Gu-891BPCMCB2xnhsaUHxz_BCMkwbbwQ76kmK=JsUdifHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-30 12:00 ` Ard Biesheuvel @ 2014-07-30 12:05 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 12:05 UTC (permalink / raw) To: Will Deacon Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w On 30 July 2014 14:00, Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > On 30 July 2014 13:30, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote: >> On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: >>> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> >>> >>> 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-5wv7dgnIgG8@public.gmane.org> >>> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >>> [ardb: added (__force void *) cast] >>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-30 12:05 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 12:05 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-30 12:00 ` Ard Biesheuvel @ 2014-07-30 12:30 ` Mark Rutland -1 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-07-30 12:30 UTC (permalink / raw) To: Ard Biesheuvel Cc: Will Deacon, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w On Wed, Jul 30, 2014 at 01:00:40PM +0100, Ard Biesheuvel wrote: > On 30 July 2014 13:30, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote: > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> > >> > >> 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-5wv7dgnIgG8@public.gmane.org> > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > >> [ardb: added (__force void *) cast] > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-30 12:30 ` Mark Rutland 0 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-07-30 12:30 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-30 12:30 ` Mark Rutland @ 2014-07-30 12:42 ` Will Deacon -1 siblings, 0 replies; 72+ messages in thread From: Will Deacon @ 2014-07-30 12:42 UTC (permalink / raw) To: Mark Rutland Cc: Ard Biesheuvel, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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-5wv7dgnIgG8@public.gmane.org> wrote: > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: > > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> > > >> > > >> 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-5wv7dgnIgG8@public.gmane.org> > > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > >> [ardb: added (__force void *) cast] > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-30 12:42 ` Will Deacon 0 siblings, 0 replies; 72+ messages in thread From: Will Deacon @ 2014-07-30 12:42 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <20140730124258.GP12239-5wv7dgnIgG8@public.gmane.org>]
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-30 12:42 ` Will Deacon @ 2014-07-30 12:49 ` Mark Rutland -1 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-07-30 12:49 UTC (permalink / raw) To: Will Deacon Cc: Ard Biesheuvel, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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-5wv7dgnIgG8@public.gmane.org> wrote: > > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: > > > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> > > > >> > > > >> 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-5wv7dgnIgG8@public.gmane.org> > > > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > >> [ardb: added (__force void *) cast] > > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-30 12:49 ` Mark Rutland 0 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-07-30 12:49 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-30 12:49 ` Mark Rutland @ 2014-07-30 13:10 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 13:10 UTC (permalink / raw) To: Mark Rutland Cc: Will Deacon, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w On 30 July 2014 14:49, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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-5wv7dgnIgG8@public.gmane.org> wrote: >> > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: >> > > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> >> > > >> >> > > >> 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-5wv7dgnIgG8@public.gmane.org> >> > > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> > > >> [ardb: added (__force void *) cast] >> > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-30 13:10 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 13:10 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <CAKv+Gu-OunL2FdzvZ6y95cKaewOyFaoCgX+Rqsg4R92yLAg=tQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-30 13:10 ` Ard Biesheuvel @ 2014-07-30 13:28 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 13:28 UTC (permalink / raw) To: Mark Rutland Cc: Will Deacon, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w On 30 July 2014 15:10, Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > On 30 July 2014 14:49, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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-5wv7dgnIgG8@public.gmane.org> wrote: >>> > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: >>> > > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> >>> > > >> >>> > > >> 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-5wv7dgnIgG8@public.gmane.org> >>> > > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >>> > > >> [ardb: added (__force void *) cast] >>> > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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) ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-30 13:28 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 13:28 UTC (permalink / raw) To: linux-arm-kernel 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) ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-30 11:30 ` Will Deacon @ 2014-07-30 19:17 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 19:17 UTC (permalink / raw) To: Will Deacon Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w ]On 30 July 2014 13:30, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote: > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> >> >> 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-5wv7dgnIgG8@public.gmane.org> >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> [ardb: added (__force void *) cast] >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-30 19:17 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 19:17 UTC (permalink / raw) To: linux-arm-kernel ]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. ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <CAKv+Gu8ne8k2NV12SyWye5aYJKHG0wHKAO+=V=1L89_hvyGopw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-30 19:17 ` Ard Biesheuvel @ 2014-07-31 9:45 ` Will Deacon -1 siblings, 0 replies; 72+ messages in thread From: Will Deacon @ 2014-07-31 9:45 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w On Wed, Jul 30, 2014 at 08:17:02PM +0100, Ard Biesheuvel wrote: > ]On 30 July 2014 13:30, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote: > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> > >> > >> 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-5wv7dgnIgG8@public.gmane.org> > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > >> [ardb: added (__force void *) cast] > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-31 9:45 ` Will Deacon 0 siblings, 0 replies; 72+ messages in thread From: Will Deacon @ 2014-07-31 9:45 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <20140731094515.GE26853-5wv7dgnIgG8@public.gmane.org>]
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-31 9:45 ` Will Deacon @ 2014-07-31 9:58 ` Mark Rutland -1 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-07-31 9:58 UTC (permalink / raw) To: Will Deacon Cc: Ard Biesheuvel, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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-5wv7dgnIgG8@public.gmane.org> wrote: > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: > > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> > > >> > > >> 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-5wv7dgnIgG8@public.gmane.org> > > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > >> [ardb: added (__force void *) cast] > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-31 9:58 ` Mark Rutland 0 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-07-31 9:58 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-31 9:58 ` Mark Rutland @ 2014-07-31 10:04 ` Will Deacon -1 siblings, 0 replies; 72+ messages in thread From: Will Deacon @ 2014-07-31 10:04 UTC (permalink / raw) To: Mark Rutland Cc: Ard Biesheuvel, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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-5wv7dgnIgG8@public.gmane.org> wrote: > > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: > > > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> > > > >> > > > >> 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-5wv7dgnIgG8@public.gmane.org> > > > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > >> [ardb: added (__force void *) cast] > > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-31 10:04 ` Will Deacon 0 siblings, 0 replies; 72+ messages in thread From: Will Deacon @ 2014-07-31 10:04 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <20140731100439.GI26853-5wv7dgnIgG8@public.gmane.org>]
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-31 10:04 ` Will Deacon @ 2014-07-31 10:16 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-31 10:16 UTC (permalink / raw) To: Will Deacon Cc: Mark Rutland, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w On 31 July 2014 12:04, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> 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-5wv7dgnIgG8@public.gmane.org> wrote: >> > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: >> > > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> >> > > >> >> > > >> 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-5wv7dgnIgG8@public.gmane.org> >> > > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> > > >> [ardb: added (__force void *) cast] >> > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-31 10:16 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-31 10:16 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-31 10:04 ` Will Deacon @ 2014-07-31 10:39 ` Mark Rutland -1 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-07-31 10:39 UTC (permalink / raw) To: Will Deacon Cc: Ard Biesheuvel, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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-5wv7dgnIgG8@public.gmane.org> wrote: > > > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: > > > > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> > > > > >> > > > > >> 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-5wv7dgnIgG8@public.gmane.org> > > > > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > > >> [ardb: added (__force void *) cast] > > > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-31 10:39 ` Mark Rutland 0 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-07-31 10:39 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-31 10:39 ` Mark Rutland @ 2014-08-01 11:35 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-08-01 11:35 UTC (permalink / raw) To: Mark Rutland Cc: Will Deacon, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w On 31 July 2014 12:39, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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-5wv7dgnIgG8@public.gmane.org> wrote: >> > > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: >> > > > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> >> > > > >> >> > > > >> 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-5wv7dgnIgG8@public.gmane.org> >> > > > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> > > > >> [ardb: added (__force void *) cast] >> > > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-08-01 11:35 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-08-01 11:35 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-31 10:04 ` Will Deacon @ 2014-07-31 14:41 ` Mark Salter -1 siblings, 0 replies; 72+ messages in thread From: Mark Salter @ 2014-07-31 14:41 UTC (permalink / raw) To: Will Deacon Cc: Mark Rutland, Ard Biesheuvel, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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-5wv7dgnIgG8@public.gmane.org> wrote: > > > > > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: > > > > >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> > > > > >> > > > > >> 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-5wv7dgnIgG8@public.gmane.org> > > > > >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > > > >> [ardb: added (__force void *) cast] > > > > >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-31 14:41 ` Mark Salter 0 siblings, 0 replies; 72+ messages in thread From: Mark Salter @ 2014-07-31 14:41 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-07-31 9:45 ` Will Deacon @ 2014-07-31 10:01 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-31 10:01 UTC (permalink / raw) To: Will Deacon Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w On 31 July 2014 11:45, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote: > On Wed, Jul 30, 2014 at 08:17:02PM +0100, Ard Biesheuvel wrote: >> ]On 30 July 2014 13:30, Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> wrote: >> > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: >> >> From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> >> >> >> >> 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-5wv7dgnIgG8@public.gmane.org> >> >> Tested-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> >> >> [ardb: added (__force void *) cast] >> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs @ 2014-07-31 10:01 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-31 10:01 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 2/3] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text 2014-07-30 10:59 ` Ard Biesheuvel @ 2014-07-30 10:59 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 10:59 UTC (permalink / raw) To: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, mark.rutland-5wv7dgnIgG8, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8 Cc: matt.fleming-ral2JQCrhuEAvxtiuMwx3w, 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Acked-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> --- 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v2 2/3] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text @ 2014-07-30 10:59 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 10:59 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
[parent not found: <1406717944-24725-3-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]
* Re: [PATCH v2 2/3] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text 2014-07-30 10:59 ` Ard Biesheuvel @ 2014-08-14 11:31 ` Mark Rutland -1 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-08-14 11:31 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, Will Deacon, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> > Acked-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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-5wv7dgnIgG8@public.gmane.org> > --- > 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 2/3] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text @ 2014-08-14 11:31 ` Mark Rutland 0 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-08-14 11:31 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied 2014-07-30 10:59 ` Ard Biesheuvel @ 2014-07-30 10:59 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 10:59 UTC (permalink / raw) To: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, mark.rutland-5wv7dgnIgG8, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8 Cc: matt.fleming-ral2JQCrhuEAvxtiuMwx3w, 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Acked-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> --- 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied @ 2014-07-30 10:59 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-07-30 10:59 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 72+ messages in thread
[parent not found: <1406717944-24725-4-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]
* Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied 2014-07-30 10:59 ` Ard Biesheuvel @ 2014-08-14 11:32 ` Mark Rutland -1 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-08-14 11:32 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, Will Deacon, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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> > --- > 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 > > ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied @ 2014-08-14 11:32 ` Mark Rutland 0 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-08-14 11:32 UTC (permalink / raw) To: linux-arm-kernel 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 > > ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied 2014-08-14 11:32 ` Mark Rutland @ 2014-08-20 17:10 ` Matt Fleming -1 siblings, 0 replies; 72+ messages in thread From: Matt Fleming @ 2014-08-20 17:10 UTC (permalink / raw) To: Ard Biesheuvel Cc: Mark Rutland, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, msalter-H+wXaHxf7aLQT0dZR+AlfA, Will Deacon, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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? -- Matt Fleming, Intel Open Source Technology Center ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied @ 2014-08-20 17:10 ` Matt Fleming 0 siblings, 0 replies; 72+ messages in thread From: Matt Fleming @ 2014-08-20 17:10 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <20140820171057.GG29733-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>]
* Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied 2014-08-20 17:10 ` Matt Fleming @ 2014-08-20 17:35 ` Mark Rutland -1 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-08-20 17:35 UTC (permalink / raw) To: Matt Fleming, Will Deacon, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A Cc: Ard Biesheuvel, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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. 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied @ 2014-08-20 17:35 ` Mark Rutland 0 siblings, 0 replies; 72+ messages in thread From: Mark Rutland @ 2014-08-20 17:35 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied 2014-08-20 17:35 ` Mark Rutland @ 2014-08-21 8:00 ` Ard Biesheuvel -1 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-08-21 8:00 UTC (permalink / raw) To: Mark Rutland Cc: Matt Fleming, Will Deacon, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w On 20 August 2014 19:35, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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? > 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied @ 2014-08-21 8:00 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-08-21 8:00 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <CAKv+Gu-3wWQJf6DTSbx68cg4BV9FX4-5t=GQ+06ikvC4M5jSkw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied 2014-08-21 8:00 ` Ard Biesheuvel @ 2014-08-21 9:22 ` Matt Fleming -1 siblings, 0 replies; 72+ messages in thread From: Matt Fleming @ 2014-08-21 9:22 UTC (permalink / raw) To: Ard Biesheuvel Cc: Mark Rutland, Will Deacon, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, msalter-H+wXaHxf7aLQT0dZR+AlfA, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied @ 2014-08-21 9:22 ` Matt Fleming 0 siblings, 0 replies; 72+ messages in thread From: Matt Fleming @ 2014-08-21 9:22 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied 2014-08-20 17:35 ` Mark Rutland @ 2014-09-09 19:39 ` Jon Masters -1 siblings, 0 replies; 72+ messages in thread From: Jon Masters @ 2014-09-09 19:39 UTC (permalink / raw) To: Mark Rutland, matt.fleming-ral2JQCrhuEAvxtiuMwx3w, Will Deacon, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A Cc: ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Salter 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-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> >>>> Acked-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> >>> >>> Acked-by: Mark Rutland <mark.rutland-5wv7dgnIgG8-XMD5yJDbdMReXY1tMh2IBg@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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied @ 2014-09-09 19:39 ` Jon Masters 0 siblings, 0 replies; 72+ messages in thread From: Jon Masters @ 2014-09-09 19:39 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <540F577A.4040709-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied 2014-09-09 19:39 ` Jon Masters @ 2014-09-10 8:39 ` Will Deacon -1 siblings, 0 replies; 72+ messages in thread From: Will Deacon @ 2014-09-10 8:39 UTC (permalink / raw) To: Jon Masters Cc: Mark Rutland, matt.fleming-ral2JQCrhuEAvxtiuMwx3w, leif.lindholm-QSEj5FYQhm4dnm+yROfE0A, ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A, linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, msalter-H+wXaHxf7aLQT0dZR+AlfA 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-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> > >>>> Acked-by: Mark Salter <msalter-H+wXaHxf7aLQT0dZR+AlfA-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> > >>> > >>> Acked-by: Mark Rutland <mark.rutland-5wv7dgnIgG8-XMD5yJDbdMReXY1tMh2IBg@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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied @ 2014-09-10 8:39 ` Will Deacon 0 siblings, 0 replies; 72+ messages in thread From: Will Deacon @ 2014-09-10 8:39 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling 2014-07-30 10:59 ` Ard Biesheuvel @ 2014-08-13 17:29 ` Leif Lindholm -1 siblings, 0 replies; 72+ messages in thread From: Leif Lindholm @ 2014-08-13 17:29 UTC (permalink / raw) To: Ard Biesheuvel Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, mark.rutland-5wv7dgnIgG8, msalter-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8, matt.fleming-ral2JQCrhuEAvxtiuMwx3w 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> Tested-by: Leif Lindholm <leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> / Leif ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling @ 2014-08-13 17:29 ` Leif Lindholm 0 siblings, 0 replies; 72+ messages in thread From: Leif Lindholm @ 2014-08-13 17:29 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <CAKv+Gu_UjRNhhiM0GPsKRdXRtmEnY6cbpY-JZ33RUMapbPYsbQ@mail.gmail.com>]
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs [not found] <CAKv+Gu_UjRNhhiM0GPsKRdXRtmEnY6cbpY-JZ33RUMapbPYsbQ@mail.gmail.com> @ 2014-08-13 12:58 ` Mark Rutland 2014-08-14 17:13 ` Catalin Marinas 0 siblings, 1 reply; 72+ messages in thread From: Mark Rutland @ 2014-08-13 12:58 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-08-13 12:58 ` [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs Mark Rutland @ 2014-08-14 17:13 ` Catalin Marinas 2014-08-14 18:10 ` Ard Biesheuvel 0 siblings, 1 reply; 72+ messages in thread From: Catalin Marinas @ 2014-08-14 17:13 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-08-14 17:13 ` Catalin Marinas @ 2014-08-14 18:10 ` Ard Biesheuvel 2014-08-15 11:57 ` Will Deacon 0 siblings, 1 reply; 72+ messages in thread From: Ard Biesheuvel @ 2014-08-14 18:10 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-08-14 18:10 ` Ard Biesheuvel @ 2014-08-15 11:57 ` Will Deacon 2014-08-15 12:07 ` Ard Biesheuvel 0 siblings, 1 reply; 72+ messages in thread From: Will Deacon @ 2014-08-15 11:57 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-08-15 11:57 ` Will Deacon @ 2014-08-15 12:07 ` Ard Biesheuvel 2014-08-15 12:53 ` Will Deacon 0 siblings, 1 reply; 72+ messages in thread From: Ard Biesheuvel @ 2014-08-15 12:07 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-08-15 12:07 ` Ard Biesheuvel @ 2014-08-15 12:53 ` Will Deacon 2014-08-15 13:28 ` Ard Biesheuvel 0 siblings, 1 reply; 72+ messages in thread From: Will Deacon @ 2014-08-15 12:53 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-08-15 12:53 ` Will Deacon @ 2014-08-15 13:28 ` Ard Biesheuvel 2014-08-15 14:35 ` Mark Salter 0 siblings, 1 reply; 72+ messages in thread From: Ard Biesheuvel @ 2014-08-15 13:28 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-08-15 13:28 ` Ard Biesheuvel @ 2014-08-15 14:35 ` Mark Salter 2014-08-15 14:38 ` Will Deacon 0 siblings, 1 reply; 72+ messages in thread From: Mark Salter @ 2014-08-15 14:35 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-08-15 14:35 ` Mark Salter @ 2014-08-15 14:38 ` Will Deacon 2014-08-17 0:06 ` Leif Lindholm 0 siblings, 1 reply; 72+ messages in thread From: Will Deacon @ 2014-08-15 14:38 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-08-15 14:38 ` Will Deacon @ 2014-08-17 0:06 ` Leif Lindholm 2014-08-18 16:47 ` Catalin Marinas 0 siblings, 1 reply; 72+ messages in thread From: Leif Lindholm @ 2014-08-17 0:06 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-08-17 0:06 ` Leif Lindholm @ 2014-08-18 16:47 ` Catalin Marinas 2014-08-18 17:22 ` Ard Biesheuvel 0 siblings, 1 reply; 72+ messages in thread From: Catalin Marinas @ 2014-08-18 16:47 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs 2014-08-18 16:47 ` Catalin Marinas @ 2014-08-18 17:22 ` Ard Biesheuvel 0 siblings, 0 replies; 72+ messages in thread From: Ard Biesheuvel @ 2014-08-18 17:22 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 72+ messages in thread
end of thread, other threads:[~2014-09-10 8:39 UTC | newest] Thread overview: 72+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-30 10:59 [PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling Ard Biesheuvel 2014-07-30 10:59 ` Ard Biesheuvel [not found] ` <1406717944-24725-1-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2014-07-30 10:59 ` [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs Ard Biesheuvel 2014-07-30 10:59 ` Ard Biesheuvel [not found] ` <1406717944-24725-2-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2014-07-30 11:30 ` Will Deacon 2014-07-30 11:30 ` Will Deacon [not found] ` <20140730113013.GL12239-5wv7dgnIgG8@public.gmane.org> 2014-07-30 12:00 ` Ard Biesheuvel 2014-07-30 12:00 ` Ard Biesheuvel [not found] ` <CAKv+Gu-891BPCMCB2xnhsaUHxz_BCMkwbbwQ76kmK=JsUdifHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-07-30 12:05 ` Ard Biesheuvel 2014-07-30 12:05 ` Ard Biesheuvel 2014-07-30 12:30 ` Mark Rutland 2014-07-30 12:30 ` Mark Rutland 2014-07-30 12:42 ` Will Deacon 2014-07-30 12:42 ` Will Deacon [not found] ` <20140730124258.GP12239-5wv7dgnIgG8@public.gmane.org> 2014-07-30 12:49 ` Mark Rutland 2014-07-30 12:49 ` Mark Rutland 2014-07-30 13:10 ` Ard Biesheuvel 2014-07-30 13:10 ` Ard Biesheuvel [not found] ` <CAKv+Gu-OunL2FdzvZ6y95cKaewOyFaoCgX+Rqsg4R92yLAg=tQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-07-30 13:28 ` Ard Biesheuvel 2014-07-30 13:28 ` Ard Biesheuvel 2014-07-30 19:17 ` Ard Biesheuvel 2014-07-30 19:17 ` Ard Biesheuvel [not found] ` <CAKv+Gu8ne8k2NV12SyWye5aYJKHG0wHKAO+=V=1L89_hvyGopw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-07-31 9:45 ` Will Deacon 2014-07-31 9:45 ` Will Deacon [not found] ` <20140731094515.GE26853-5wv7dgnIgG8@public.gmane.org> 2014-07-31 9:58 ` Mark Rutland 2014-07-31 9:58 ` Mark Rutland 2014-07-31 10:04 ` Will Deacon 2014-07-31 10:04 ` Will Deacon [not found] ` <20140731100439.GI26853-5wv7dgnIgG8@public.gmane.org> 2014-07-31 10:16 ` Ard Biesheuvel 2014-07-31 10:16 ` Ard Biesheuvel 2014-07-31 10:39 ` Mark Rutland 2014-07-31 10:39 ` Mark Rutland 2014-08-01 11:35 ` Ard Biesheuvel 2014-08-01 11:35 ` Ard Biesheuvel 2014-07-31 14:41 ` Mark Salter 2014-07-31 14:41 ` Mark Salter 2014-07-31 10:01 ` Ard Biesheuvel 2014-07-31 10:01 ` Ard Biesheuvel 2014-07-30 10:59 ` [PATCH v2 2/3] arm64/efi: efistub: cover entire static mem footprint in PE/COFF .text Ard Biesheuvel 2014-07-30 10:59 ` Ard Biesheuvel [not found] ` <1406717944-24725-3-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2014-08-14 11:31 ` Mark Rutland 2014-08-14 11:31 ` Mark Rutland 2014-07-30 10:59 ` [PATCH v2 3/3] arm64/efi: efistub: don't abort if base of DRAM is occupied Ard Biesheuvel 2014-07-30 10:59 ` Ard Biesheuvel [not found] ` <1406717944-24725-4-git-send-email-ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 2014-08-14 11:32 ` Mark Rutland 2014-08-14 11:32 ` Mark Rutland 2014-08-20 17:10 ` Matt Fleming 2014-08-20 17:10 ` Matt Fleming [not found] ` <20140820171057.GG29733-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org> 2014-08-20 17:35 ` Mark Rutland 2014-08-20 17:35 ` Mark Rutland 2014-08-21 8:00 ` Ard Biesheuvel 2014-08-21 8:00 ` Ard Biesheuvel [not found] ` <CAKv+Gu-3wWQJf6DTSbx68cg4BV9FX4-5t=GQ+06ikvC4M5jSkw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2014-08-21 9:22 ` Matt Fleming 2014-08-21 9:22 ` Matt Fleming 2014-09-09 19:39 ` Jon Masters 2014-09-09 19:39 ` Jon Masters [not found] ` <540F577A.4040709-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2014-09-10 8:39 ` Will Deacon 2014-09-10 8:39 ` Will Deacon 2014-08-13 17:29 ` [PATCH 0/3 v2] arm64/efi: improve TEXT_OFFSET handling Leif Lindholm 2014-08-13 17:29 ` Leif Lindholm [not found] <CAKv+Gu_UjRNhhiM0GPsKRdXRtmEnY6cbpY-JZ33RUMapbPYsbQ@mail.gmail.com> 2014-08-13 12:58 ` [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs Mark Rutland 2014-08-14 17:13 ` Catalin Marinas 2014-08-14 18:10 ` Ard Biesheuvel 2014-08-15 11:57 ` Will Deacon 2014-08-15 12:07 ` Ard Biesheuvel 2014-08-15 12:53 ` Will Deacon 2014-08-15 13:28 ` Ard Biesheuvel 2014-08-15 14:35 ` Mark Salter 2014-08-15 14:38 ` Will Deacon 2014-08-17 0:06 ` Leif Lindholm 2014-08-18 16:47 ` Catalin Marinas 2014-08-18 17:22 ` Ard Biesheuvel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.