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

[Ard Biesheuvel]

On 30 July 2014 13:30, Will Deacon <will.deacon at arm.com> wrote:
> On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote:
>> From: Mark Rutland <mark.rutland at 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 at arm.com>
>> Tested-by: Mark Salter <msalter at redhat.com>
>> [ardb: added (__force void *) cast]
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel at 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.