| Message ID | 1a57b23ba809626854ceff612d3fed9e19ef5e10.1425884424.git.jan.kiszka@siemens.com |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
On Mon, Mar 09, 2015 at 08:00:18AM +0100, Jan Kiszka wrote: > In this case the secure code lives in RAM, and hence the memory node in > the device tree needs to be adjusted. This avoids that the OS will map > and possibly access the reservation. > > Add support for setting CONFIG_ARMV7_SECURE_RESERVE_SIZE to carve out > such a region. We only support cutting off memory from the beginning or > the end of a RAM bank as we do not want to increase their number (which > would happen if punching a hole) for simplicity reasons > > This will be used in a subsequent patch for Jetson-TK1. > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > --- > arch/arm/cpu/armv7/virt-dt.c | 29 +++++++++++++++++++++++++++++ My concern here is that this looks a lot like things we would re-use on armv8 and we're making them potentially needlessly v7-centric. If nothing else, the function names should be generic and this be the v7 implementation of them, yes?
Am 2015-03-11 um 16:12 schrieb Tom Rini: > On Mon, Mar 09, 2015 at 08:00:18AM +0100, Jan Kiszka wrote: > >> In this case the secure code lives in RAM, and hence the memory node in >> the device tree needs to be adjusted. This avoids that the OS will map >> and possibly access the reservation. >> >> Add support for setting CONFIG_ARMV7_SECURE_RESERVE_SIZE to carve out >> such a region. We only support cutting off memory from the beginning or >> the end of a RAM bank as we do not want to increase their number (which >> would happen if punching a hole) for simplicity reasons >> >> This will be used in a subsequent patch for Jetson-TK1. >> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >> --- >> arch/arm/cpu/armv7/virt-dt.c | 29 +++++++++++++++++++++++++++++ > > My concern here is that this looks a lot like things we would re-use on > armv8 and we're making them potentially needlessly v7-centric. If > nothing else, the function names should be generic and this be the v7 > implementation of them, yes? I didn't look into v8's needs and state yet, so I cannot comment on this. But my feeling is that renaming is only relevant if we expect PSCI code that invokes this to be shared by both. Jan
On Wed, Mar 11, 2015 at 11:12:25AM -0400, Tom Rini wrote: > * PGP Signed by an unknown key > > On Mon, Mar 09, 2015 at 08:00:18AM +0100, Jan Kiszka wrote: > > > In this case the secure code lives in RAM, and hence the memory node in > > the device tree needs to be adjusted. This avoids that the OS will map > > and possibly access the reservation. > > > > Add support for setting CONFIG_ARMV7_SECURE_RESERVE_SIZE to carve out > > such a region. We only support cutting off memory from the beginning or > > the end of a RAM bank as we do not want to increase their number (which > > would happen if punching a hole) for simplicity reasons > > > > This will be used in a subsequent patch for Jetson-TK1. > > > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > > --- > > arch/arm/cpu/armv7/virt-dt.c | 29 +++++++++++++++++++++++++++++ > > My concern here is that this looks a lot like things we would re-use on > armv8 and we're making them potentially needlessly v7-centric. If > nothing else, the function names should be generic and this be the v7 > implementation of them, yes? In my opinion it's fine to go along with this and then refactor things once we have an ARMv8 board that makes use of this. Thierry
On Thu, Mar 12, 2015 at 09:18:01AM +0100, Thierry Reding wrote: > On Wed, Mar 11, 2015 at 11:12:25AM -0400, Tom Rini wrote: > > * PGP Signed by an unknown key > > > > On Mon, Mar 09, 2015 at 08:00:18AM +0100, Jan Kiszka wrote: > > > > > In this case the secure code lives in RAM, and hence the memory node in > > > the device tree needs to be adjusted. This avoids that the OS will map > > > and possibly access the reservation. > > > > > > Add support for setting CONFIG_ARMV7_SECURE_RESERVE_SIZE to carve out > > > such a region. We only support cutting off memory from the beginning or > > > the end of a RAM bank as we do not want to increase their number (which > > > would happen if punching a hole) for simplicity reasons > > > > > > This will be used in a subsequent patch for Jetson-TK1. > > > > > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > > > --- > > > arch/arm/cpu/armv7/virt-dt.c | 29 +++++++++++++++++++++++++++++ > > > > My concern here is that this looks a lot like things we would re-use on > > armv8 and we're making them potentially needlessly v7-centric. If > > nothing else, the function names should be generic and this be the v7 > > implementation of them, yes? > > In my opinion it's fine to go along with this and then refactor things > once we have an ARMv8 board that makes use of this. I'll live with it then but I expect the time to refactor things to approach really quickly too.
diff --git a/arch/arm/cpu/armv7/virt-dt.c b/arch/arm/cpu/armv7/virt-dt.c index ad19e4c..06edeec 100644 --- a/arch/arm/cpu/armv7/virt-dt.c +++ b/arch/arm/cpu/armv7/virt-dt.c @@ -16,6 +16,7 @@ */ #include <common.h> +#include <errno.h> #include <stdio_dev.h> #include <linux/ctype.h> #include <linux/types.h> @@ -88,6 +89,34 @@ static int fdt_psci(void *fdt) return 0; } +int armv7_apply_memory_carveout(u64 *start, u64 *size) +{ +#ifdef CONFIG_ARMV7_SECURE_RESERVE_SIZE + if (*start + *size < CONFIG_ARMV7_SECURE_BASE || + *start >= (u64)CONFIG_ARMV7_SECURE_BASE + + CONFIG_ARMV7_SECURE_RESERVE_SIZE) + return 0; + + /* carveout must be at the beginning or the end of the bank */ + if (*start == CONFIG_ARMV7_SECURE_BASE || + *start + *size == (u64)CONFIG_ARMV7_SECURE_BASE + + CONFIG_ARMV7_SECURE_RESERVE_SIZE) { + if (*size < CONFIG_ARMV7_SECURE_RESERVE_SIZE) { + debug("Secure monitor larger than RAM bank!?\n"); + return -EINVAL; + } + *size -= CONFIG_ARMV7_SECURE_RESERVE_SIZE; + if (*start == CONFIG_ARMV7_SECURE_BASE) + *start += CONFIG_ARMV7_SECURE_RESERVE_SIZE; + return 0; + } + debug("Secure monitor not located at beginning or end of RAM bank\n"); + return -EINVAL; +#else /* !CONFIG_ARMV7_SECURE_RESERVE_SIZE */ + return 0; +#endif +} + int armv7_update_dt(void *fdt) { if (!armv7_boot_nonsec()) diff --git a/arch/arm/include/asm/armv7.h b/arch/arm/include/asm/armv7.h index edb3b80..7843ba7 100644 --- a/arch/arm/include/asm/armv7.h +++ b/arch/arm/include/asm/armv7.h @@ -124,6 +124,7 @@ void v7_outer_cache_inval_range(u32 start, u32 end); #if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT) int armv7_init_nonsec(void); +int armv7_apply_memory_carveout(u64 *start, u64 *size); int armv7_update_dt(void *fdt); bool armv7_boot_nonsec(void); diff --git a/arch/arm/lib/bootm-fdt.c b/arch/arm/lib/bootm-fdt.c index d4f1578..7b88739 100644 --- a/arch/arm/lib/bootm-fdt.c +++ b/arch/arm/lib/bootm-fdt.c @@ -31,6 +31,11 @@ int arch_fixup_fdt(void *blob) for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) { start[bank] = bd->bi_dram[bank].start; size[bank] = bd->bi_dram[bank].size; +#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT) + ret = armv7_apply_memory_carveout(&start[bank], &size[bank]); + if (ret) + return ret; +#endif } ret = fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
In this case the secure code lives in RAM, and hence the memory node in the device tree needs to be adjusted. This avoids that the OS will map and possibly access the reservation. Add support for setting CONFIG_ARMV7_SECURE_RESERVE_SIZE to carve out such a region. We only support cutting off memory from the beginning or the end of a RAM bank as we do not want to increase their number (which would happen if punching a hole) for simplicity reasons This will be used in a subsequent patch for Jetson-TK1. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- arch/arm/cpu/armv7/virt-dt.c | 29 +++++++++++++++++++++++++++++ arch/arm/include/asm/armv7.h | 1 + arch/arm/lib/bootm-fdt.c | 5 +++++ 3 files changed, 35 insertions(+)