linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 1/3] arm: mm: reordering memory type table
Date: Mon, 24 Sep 2018 17:22:03 +0100	[thread overview]
Message-ID: <20180924162202.GD52978@arrakis.emea.arm.com> (raw)
In-Reply-To: <20180917004451.174527-2-minchan@kernel.org>

On Mon, Sep 17, 2018 at 09:44:49AM +0900, Minchan Kim wrote:
> To use bit 5 in page table as L_PTE_SPECIAL, we need a room for that.
> It seems we don't need 4 bits for the memory type with ARMv6+.
> If it's true, let's reorder bits to make bit 5 free.
> 
> We will use the bit for L_PTE_SPECIAL in next patch.
> 
> A note from Catalin
> "
> > Anyway, on ARMv7 or ARMv6+LPAE, the non-shared device gets mapped to

I meant 'ARMv7+LPAE' since ARMv6 never had the LPAE feature (please
correct the code comment below as well).

I was wrong with the classic ARMv7, only ARMv7+LPAE makes all device
memory shareable in hardware (even if not enabled). With classic ARMv7
(that is pre-Cortex-A7/A15), the shareable bit in combination with PRRR
allows the Device Non-shareable configuration.

Anyway, it doesn't matter here since the L_PTE_SHARED bit is set
separately in the mem_types[] array, the L_PTE_MT_* definitions are just
for the actual memory type ignoring shareability. We just need to make
sure the comments are correct.

> > shared device in hardware. Looking through the arm32 code, it seems that
> > MT_DEVICE_NONSHARED is used by arch/arm/mach-shmobile/setup-r8a7779.c
> > and IIUC that's a v7 platform (R-Car H1, Cortex-A9). I think the above
> > should be defined to L_PTE_MT_DEV_SHARED, unless I miss any place where
> > DEV_NONSHARED is relevant on ARMv6 (adding Simon to confirm on shmbile).

It would be good to figure out the DEV_NONSHARED on ARMv6 relevance. I
don't think we break R-Car H1 since the shareability bit wouldn't be set
for DEV_NONSHARED.

> diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h
> index 92fd2c8a9af0..514b13c27b43 100644
> --- a/arch/arm/include/asm/pgtable-2level.h
> +++ b/arch/arm/include/asm/pgtable-2level.h
> @@ -164,14 +164,25 @@
>  #define L_PTE_MT_BUFFERABLE	(_AT(pteval_t, 0x01) << 2)	/* 0001 */
>  #define L_PTE_MT_WRITETHROUGH	(_AT(pteval_t, 0x02) << 2)	/* 0010 */
>  #define L_PTE_MT_WRITEBACK	(_AT(pteval_t, 0x03) << 2)	/* 0011 */
> +#define L_PTE_MT_DEV_SHARED	(_AT(pteval_t, 0x04) << 2)	/* 0100 */
> +#define L_PTE_MT_VECTORS	(_AT(pteval_t, 0x05) << 2)	/* 0101 */
>  #define L_PTE_MT_MINICACHE	(_AT(pteval_t, 0x06) << 2)	/* 0110 (sa1100, xscale) */
>  #define L_PTE_MT_WRITEALLOC	(_AT(pteval_t, 0x07) << 2)	/* 0111 */
> -#define L_PTE_MT_DEV_SHARED	(_AT(pteval_t, 0x04) << 2)	/* 0100 */
> -#define L_PTE_MT_DEV_NONSHARED	(_AT(pteval_t, 0x0c) << 2)	/* 1100 */
> +#if defined(CONFIG_CPU_V7) || defined (CONFIG_CPU_V6) || defined(CONFIG_CPU_V6K)
> +/*
> + * On ARMv7 or ARMv6+LPAE, the non-shared device gets mapped to
> + * shared device in hardware.
> + */

I would change this to something like:

/*
 * On ARMv7 or ARMv7+LPAE, the non-shared and shared device types get
 * mapped to the same TEX remapping index. On classic ARMv7, the
 * shareability is controlled by the PRRR[17:16] field, indexed by
 * L_PTE_SHARED. On ARMv7+LPAE the device mapping is always shareable.
 */

> +#define L_PTE_MT_DEV_NONSHARED	L_PTE_MT_DEV_SHARED
> +#define L_PTE_MT_DEV_WC		L_PTE_MT_BUFFERABLE
> +#define L_PTE_MT_DEV_CACHED	L_PTE_MT_WRITEBACK
> +#define L_PTE_MT_MASK		(_AT(pteval_t, 0x07) << 2)
> +#else
>  #define L_PTE_MT_DEV_WC		(_AT(pteval_t, 0x09) << 2)	/* 1001 */
>  #define L_PTE_MT_DEV_CACHED	(_AT(pteval_t, 0x0b) << 2)	/* 1011 */
> -#define L_PTE_MT_VECTORS	(_AT(pteval_t, 0x0f) << 2)	/* 1111 */
> -#define L_PTE_MT_MASK		(_AT(pteval_t, 0x0f) << 2)
> +#define L_PTE_MT_DEV_NONSHARED	(_AT(pteval_t, 0x0c) << 2)	/* 1100 */
> +#define L_PTE_MT_MASK           (_AT(pteval_t, 0x0f) << 2)
> +#endif
>  
>  #ifndef __ASSEMBLY__
>  
> diff --git a/arch/arm/mm/proc-macros.S b/arch/arm/mm/proc-macros.S
> index 81d0efb055c6..367a89d5aeca 100644
> --- a/arch/arm/mm/proc-macros.S
> +++ b/arch/arm/mm/proc-macros.S
> @@ -138,7 +138,7 @@
>  	.long	PTE_CACHEABLE					@ L_PTE_MT_WRITETHROUGH
>  	.long	PTE_CACHEABLE | PTE_BUFFERABLE			@ L_PTE_MT_WRITEBACK
>  	.long	PTE_BUFFERABLE					@ L_PTE_MT_DEV_SHARED
> -	.long	0x00						@ unused
> +	.long	PTE_CACHEABLE | PTE_BUFFERABLE | PTE_EXT_APX	@ L_PTE_MT_VECTORS
>  	.long	0x00						@ L_PTE_MT_MINICACHE (not present)
>  	.long	PTE_EXT_TEX(1) | PTE_CACHEABLE | PTE_BUFFERABLE	@ L_PTE_MT_WRITEALLOC
>  	.long	0x00						@ unused
> @@ -148,7 +148,7 @@
>  	.long	PTE_EXT_TEX(2)					@ L_PTE_MT_DEV_NONSHARED
>  	.long	0x00						@ unused
>  	.long	0x00						@ unused
> -	.long	PTE_CACHEABLE | PTE_BUFFERABLE | PTE_EXT_APX	@ L_PTE_MT_VECTORS
> +	.long	0x00						@ unused
>  	.endm

Looking at the L_PTE_MT_VECTORS uses, I don't think this gives you what
you intended. vecs_pgprot in build_mem_type_table() actually combines
the cache policy bits with L_PTE_MT_VECTORS and this might have been the
reason why it was on the last position (all bits 1). So the default
cachepolicy of L_PTE_MT_WRITEBACK or'ed with the new L_PTE_MT_VECTORS
gives you 0b0111 which is position 7 instead of 5. This would map onto
L_PTE_MT_WRITEALLOC (which is not that bad) but misses the APX bit which
marks the vectors page r/w for kernel and ro for user.

I don't think this matters since the kernel no longer writes to the
vectors page at run-time but it needs cleaning up a bit (and testing in
case I missed something). IOW, do we still need a dedicated mapping type
for the vectors or we can simply use the read-only user page attributes?

-- 
Catalin

  parent reply	other threads:[~2018-09-24 16:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17  0:44 [PATCH v1 0/3] arm: support get_user_pages_fast Minchan Kim
2018-09-17  0:44 ` [PATCH v1 1/3] arm: mm: reordering memory type table Minchan Kim
2018-09-21  1:43   ` Minchan Kim
2018-09-24 16:22   ` Catalin Marinas [this message]
2018-09-28  6:34     ` Minchan Kim
2018-09-17  0:44 ` [PATCH v1 2/3] arm: mm: introduce L_PTE_SPECIAL Minchan Kim
2018-09-17  0:44 ` [PATCH v1 3/3] arm: mm: support get_user_pages_fast Minchan Kim

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=20180924162202.GD52978@arrakis.emea.arm.com \
    --to=catalin.marinas@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).