From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] arm64: extend ioremap for cacheable non-shareable memory
Date: Fri, 21 Apr 2017 10:11:57 +0100 [thread overview]
Message-ID: <20170421091156.GA6406@leverpostej> (raw)
In-Reply-To: <1492716858-24509-2-git-send-email-Haiying.Wang@nxp.com>
Hi,
I notice you missed Catalin and Will from Cc. In future, please ensure
that you Cc them when altering arm64 arch code.
On Thu, Apr 20, 2017 at 03:34:16PM -0400, Haiying Wang wrote:
> NXP arm64 based SoC needs to allocate cacheable and
> non-shareable memory for the software portals of
> Queue manager, so we extend the arm64 ioremap support
> for this memory attribute.
NAK to this patch.
It is not possible to safely use Non-Shareable attributes in Linux page
tables, given that these page tables are shared by all PEs (i.e. CPUs).
My understanding is that if several PEs map a region as Non-Shareable,
the usual background behaviour of the PEs (e.g. speculation,
prefetching, natural eviction) mean that uniprocessor semantics are not
guaranteed (i.e. a read following a write may see stale data).
For example, in a system like:
+------+ +------+
| PE-a | | PE-b |
+------+ +------+
| L1-a | | L1-b |
+------+ +------+
|| ||
+----------------+
| Shared cache |
+----------------+
||
+----------------+
| Memory |
+----------------+
... you could have a sequence like:
1) PE-a allocates a line into L1-a for address X in preparation for a
store.
2) PE-b allocates a line into L1-b for the same address X as a result of
speculation.
3) PE-a makes a store to the line in L1-a. Since address X is mapped as
Non-shareable, no snoops are performed to keep other copies of the
line in sync.
4) As a result of explicit maintenance or as a natural eviction, L1-a
evicts its line into shared cache. The shared cache subsequently
evicts this to memory.
5) L1-b evicts its line to shared cache as a natural eviction.
6) L1-a fetches the line from shared cache in response to a load by
PE-a, returning stale data (i.e. the store is lost).
No amount of cache maintenance can avoid this. In general, Non-Shareable
mappings are a bad idea.
Thanks,
Mark.
> Signed-off-by: Haiying Wang <Haiying.Wang@nxp.com>
> ---
> arch/arm64/include/asm/io.h | 1 +
> arch/arm64/include/asm/pgtable-prot.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 0c00c87..b6f03e7 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -170,6 +170,7 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
> #define ioremap_nocache(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
> #define ioremap_wc(addr, size) __ioremap((addr), (size), __pgprot(PROT_NORMAL_NC))
> #define ioremap_wt(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
> +#define ioremap_cache_ns(addr, size) __ioremap((addr), (size), __pgprot(PROT_NORMAL_NS))
> #define iounmap __iounmap
>
> /*
> diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
> index 2142c77..7fc7910 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@ -42,6 +42,7 @@
> #define PROT_NORMAL_NC (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_NC))
> #define PROT_NORMAL_WT (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_WT))
> #define PROT_NORMAL (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL))
> +#define PROT_NORMAL_NS (PTE_TYPE_PAGE | PTE_AF | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL))
>
> #define PROT_SECT_DEVICE_nGnRE (PROT_SECT_DEFAULT | PMD_SECT_PXN | PMD_SECT_UXN | PMD_ATTRINDX(MT_DEVICE_nGnRE))
> #define PROT_SECT_NORMAL (PROT_SECT_DEFAULT | PMD_SECT_PXN | PMD_SECT_UXN | PMD_ATTRINDX(MT_NORMAL))
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Haiying Wang <Haiying.Wang@nxp.com>
Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
linux-arm-kernel@lists.infradead.org, roy.pledge@nxp.com,
stuyoder@gmail.com, catalin.marinas@arm.com, will.deacon@arm.com
Subject: Re: [PATCH 1/3] arm64: extend ioremap for cacheable non-shareable memory
Date: Fri, 21 Apr 2017 10:11:57 +0100 [thread overview]
Message-ID: <20170421091156.GA6406@leverpostej> (raw)
In-Reply-To: <1492716858-24509-2-git-send-email-Haiying.Wang@nxp.com>
Hi,
I notice you missed Catalin and Will from Cc. In future, please ensure
that you Cc them when altering arm64 arch code.
On Thu, Apr 20, 2017 at 03:34:16PM -0400, Haiying Wang wrote:
> NXP arm64 based SoC needs to allocate cacheable and
> non-shareable memory for the software portals of
> Queue manager, so we extend the arm64 ioremap support
> for this memory attribute.
NAK to this patch.
It is not possible to safely use Non-Shareable attributes in Linux page
tables, given that these page tables are shared by all PEs (i.e. CPUs).
My understanding is that if several PEs map a region as Non-Shareable,
the usual background behaviour of the PEs (e.g. speculation,
prefetching, natural eviction) mean that uniprocessor semantics are not
guaranteed (i.e. a read following a write may see stale data).
For example, in a system like:
+------+ +------+
| PE-a | | PE-b |
+------+ +------+
| L1-a | | L1-b |
+------+ +------+
|| ||
+----------------+
| Shared cache |
+----------------+
||
+----------------+
| Memory |
+----------------+
... you could have a sequence like:
1) PE-a allocates a line into L1-a for address X in preparation for a
store.
2) PE-b allocates a line into L1-b for the same address X as a result of
speculation.
3) PE-a makes a store to the line in L1-a. Since address X is mapped as
Non-shareable, no snoops are performed to keep other copies of the
line in sync.
4) As a result of explicit maintenance or as a natural eviction, L1-a
evicts its line into shared cache. The shared cache subsequently
evicts this to memory.
5) L1-b evicts its line to shared cache as a natural eviction.
6) L1-a fetches the line from shared cache in response to a load by
PE-a, returning stale data (i.e. the store is lost).
No amount of cache maintenance can avoid this. In general, Non-Shareable
mappings are a bad idea.
Thanks,
Mark.
> Signed-off-by: Haiying Wang <Haiying.Wang@nxp.com>
> ---
> arch/arm64/include/asm/io.h | 1 +
> arch/arm64/include/asm/pgtable-prot.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 0c00c87..b6f03e7 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -170,6 +170,7 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
> #define ioremap_nocache(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
> #define ioremap_wc(addr, size) __ioremap((addr), (size), __pgprot(PROT_NORMAL_NC))
> #define ioremap_wt(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
> +#define ioremap_cache_ns(addr, size) __ioremap((addr), (size), __pgprot(PROT_NORMAL_NS))
> #define iounmap __iounmap
>
> /*
> diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
> index 2142c77..7fc7910 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@ -42,6 +42,7 @@
> #define PROT_NORMAL_NC (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_NC))
> #define PROT_NORMAL_WT (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_WT))
> #define PROT_NORMAL (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL))
> +#define PROT_NORMAL_NS (PTE_TYPE_PAGE | PTE_AF | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL))
>
> #define PROT_SECT_DEVICE_nGnRE (PROT_SECT_DEFAULT | PMD_SECT_PXN | PMD_SECT_UXN | PMD_ATTRINDX(MT_DEVICE_nGnRE))
> #define PROT_SECT_NORMAL (PROT_SECT_DEFAULT | PMD_SECT_PXN | PMD_SECT_UXN | PMD_ATTRINDX(MT_NORMAL))
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2017-04-21 9:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 19:34 [PATCH 0/3] bus: fsl-mc: dpio: udpate QMan CENA region Haiying Wang
2017-04-20 19:34 ` Haiying Wang
2017-04-20 19:34 ` [PATCH 1/3] arm64: extend ioremap for cacheable non-shareable memory Haiying Wang
2017-04-20 19:34 ` Haiying Wang
2017-04-21 9:11 ` Mark Rutland [this message]
2017-04-21 9:11 ` Mark Rutland
2017-04-21 14:30 ` Roy Pledge
2017-04-21 14:30 ` Roy Pledge
2017-04-25 13:42 ` Mark Rutland
2017-04-25 13:42 ` Mark Rutland
2017-04-20 19:34 ` [PATCH 2/3] bus: fsl-mc: dpio: enable qbman CENA portal memory access Haiying Wang
2017-04-20 19:34 ` Haiying Wang
2017-04-21 9:25 ` Mark Rutland
2017-04-21 9:25 ` Mark Rutland
2017-04-21 14:37 ` Catalin Marinas
2017-04-21 14:37 ` Catalin Marinas
2017-04-20 19:34 ` [PATCH 3/3] bus: fsl-mc: dpio: change CENA regs to be cacheable Haiying Wang
2017-04-20 19:34 ` Haiying Wang
2017-04-21 9:27 ` Mark Rutland
2017-04-21 9:27 ` Mark Rutland
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=20170421091156.GA6406@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.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: link
Be 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.