From: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org> Cc: "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>, Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>, "leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" <leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, "msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" <msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> Subject: Re: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs Date: Wed, 30 Jul 2014 14:05:08 +0200 [thread overview] Message-ID: <CAKv+Gu8rg=Th0OggHggSFEpLq5buR3vsCwR74TeyO5g85pt2Hw@mail.gmail.com> (raw) In-Reply-To: <CAKv+Gu-891BPCMCB2xnhsaUHxz_BCMkwbbwQ76kmK=JsUdifHQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 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.
WARNING: multiple messages have this Message-ID (diff)
From: ard.biesheuvel@linaro.org (Ard Biesheuvel) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 1/3] arm64: spin-table: handle unmapped cpu-release-addrs Date: Wed, 30 Jul 2014 14:05:08 +0200 [thread overview] Message-ID: <CAKv+Gu8rg=Th0OggHggSFEpLq5buR3vsCwR74TeyO5g85pt2Hw@mail.gmail.com> (raw) In-Reply-To: <CAKv+Gu-891BPCMCB2xnhsaUHxz_BCMkwbbwQ76kmK=JsUdifHQ@mail.gmail.com> 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.
next prev parent reply other threads:[~2014-07-30 12:05 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 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 [this message] 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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAKv+Gu8rg=Th0OggHggSFEpLq5buR3vsCwR74TeyO5g85pt2Hw@mail.gmail.com' \ --to=ard.biesheuvel-qsej5fyqhm4dnm+yrofe0a@public.gmane.org \ --cc=Mark.Rutland-5wv7dgnIgG8@public.gmane.org \ --cc=leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \ --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \ --cc=msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \ --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.