From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ard Biesheuvel Subject: Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs Date: Wed, 30 Jul 2014 14:00:40 +0200 Message-ID: References: <1406717944-24725-1-git-send-email-ard.biesheuvel@linaro.org> <1406717944-24725-2-git-send-email-ard.biesheuvel@linaro.org> <20140730113013.GL12239@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20140730113013.GL12239-5wv7dgnIgG8@public.gmane.org> Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Will Deacon Cc: "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Mark Rutland , "leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , "msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" List-Id: linux-efi@vger.kernel.org On 30 July 2014 13:30, Will Deacon wrote: > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: >> From: Mark Rutland >> >> 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 >> Tested-by: Mark Salter >> [ardb: added (__force void *) cast] >> Signed-off-by: Ard Biesheuvel >> --- >> 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: ard.biesheuvel@linaro.org (Ard Biesheuvel) Date: Wed, 30 Jul 2014 14:00:40 +0200 Subject: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs In-Reply-To: <20140730113013.GL12239@arm.com> References: <1406717944-24725-1-git-send-email-ard.biesheuvel@linaro.org> <1406717944-24725-2-git-send-email-ard.biesheuvel@linaro.org> <20140730113013.GL12239@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 30 July 2014 13:30, Will Deacon wrote: > On Wed, Jul 30, 2014 at 11:59:02AM +0100, Ard Biesheuvel wrote: >> From: Mark Rutland >> >> 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 >> Tested-by: Mark Salter >> [ardb: added (__force void *) cast] >> Signed-off-by: Ard Biesheuvel >> --- >> 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.