On 30 July 2014 14:00, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > On 30 July 2014 13:30, Will Deacon <will.deacon@xxxxxxx> wrote: >> On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: >>> From: Mark Rutland <mark.rutland@xxxxxxx> >>> >>> 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@xxxxxxx> >>> Tested-by: Mark Salter <msalter@xxxxxxxxxx> >>> [ardb: added (__force void *) cast] >>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> >>> --- >>> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
