From: Steve Capper <Steve.Capper@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>, nd <nd@arm.com>,
"will@kernel.org" <will@kernel.org>,
Anshuman Khandual <Anshuman.Khandual@arm.com>
Subject: Re: [PATCH v2 2/4] arm64: mm: extend linear region for 52-bit VA configurations
Date: Tue, 13 Oct 2020 16:51:39 +0000 [thread overview]
Message-ID: <68c0ac2b-e622-ee29-138b-1415cb80becb@arm.com> (raw)
In-Reply-To: <20201008153602.9467-3-ardb@kernel.org>
Hi Ard,
One comment below...
On 08/10/2020 16:36, Ard Biesheuvel wrote:
> For historical reasons, the arm64 kernel VA space is configured as two
> equally sized halves, i.e., on a 48-bit VA build, the VA space is split
> into a 47-bit vmalloc region and a 47-bit linear region.
>
> When support for 52-bit virtual addressing was added, this equal split
> was kept, resulting in a substantial waste of virtual address space in
> the linear region:
>
> 48-bit VA 52-bit VA
> 0xffff_ffff_ffff_ffff +-------------+ +-------------+
> | vmalloc | | vmalloc |
> 0xffff_8000_0000_0000 +-------------+ _PAGE_END(48) +-------------+
> | linear | : :
> 0xffff_0000_0000_0000 +-------------+ : :
> : : : :
> : : : :
> : : : :
> : : : currently :
> : unusable : : :
> : : : unused :
> : by : : :
> : : : :
> : hardware : : :
> : : : :
> 0xfff8_0000_0000_0000 : : _PAGE_END(52) +-------------+
> : : | |
> : : | |
> : : | |
> : : | |
> : : | |
> : unusable : | |
> : : | linear |
> : by : | |
> : : | region |
> : hardware : | |
> : : | |
> : : | |
> : : | |
> : : | |
> : : | |
> : : | |
> 0xfff0_0000_0000_0000 +-------------+ PAGE_OFFSET +-------------+
>
> As illustrated above, the 52-bit VA kernel uses 47 bits for the vmalloc
> space (as before), to ensure that a single 64k granule kernel image can
> support any 64k granule capable system, regardless of whether it supports
> the 52-bit virtual addressing extension. However, due to the fact that
> the VA space is still split in equal halves, the linear region is only
> 2^51 bytes in size, wasting almost half of the 52-bit VA space.
>
> Let's fix this, by abandoning the equal split, and simply assigning all
> VA space outside of the vmalloc region to the linear region.
>
> The KASAN shadow region is reconfigured so that it ends at the start of
> the vmalloc region, and grows downwards. That way, the arrangement of
> the vmalloc space (which contains kernel mappings, modules, BPF region,
> the vmemmap array etc) is identical between non-KASAN and KASAN builds,
> which aids debugging.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> Documentation/arm64/kasan-offsets.sh | 3 +--
> Documentation/arm64/memory.rst | 19 +++++++++----------
> arch/arm64/Kconfig | 20 ++++++++++----------
> arch/arm64/include/asm/memory.h | 12 +++++-------
> arch/arm64/mm/init.c | 2 +-
> 5 files changed, 26 insertions(+), 30 deletions(-)
>
[...]
> diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst
> index cf03b3290800..ee51eb66a578 100644
> --- a/Documentation/arm64/memory.rst
> +++ b/Documentation/arm64/memory.rst
> @@ -32,10 +32,10 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
> -----------------------------------------------------------------------
> 0000000000000000 0000ffffffffffff 256TB user
> ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map
> - ffff800000000000 ffff9fffffffffff 32TB kasan shadow region
> - ffffa00000000000 ffffa00007ffffff 128MB bpf jit region
> - ffffa00008000000 ffffa0000fffffff 128MB modules
> - ffffa00010000000 fffffdffbffeffff ~93TB vmalloc
> +[ ffff600000000000 ffff7fffffffffff ] 32TB [ kasan shadow region ]
We have the KASAN shadow region intersecting with the kernel logical
memory map now. Could this present a problem if both the KASAN and
phys_to_virt paths land on the same VA? Or is that not possible? (Also
what about smaller VA sizes?)
If it is a problem, could carving out the appropriate memblocks (and
warning the user) be a way forward?
Cheers,
--
Steve
_______________________________________________
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:[~2020-10-13 16:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 15:35 [PATCH v2 0/4] arm64: mm: optimize VA space organization for 52-bit Ard Biesheuvel
2020-10-08 15:35 ` [PATCH v2 1/4] arm64: mm: use single quantity to represent the PA to VA translation Ard Biesheuvel
2020-10-13 16:14 ` Steve Capper
2020-10-13 16:47 ` Steve Capper
2020-10-15 10:47 ` Will Deacon
2020-10-08 15:36 ` [PATCH v2 2/4] arm64: mm: extend linear region for 52-bit VA configurations Ard Biesheuvel
2020-10-13 16:51 ` Steve Capper [this message]
2020-10-13 16:57 ` Ard Biesheuvel
2020-10-13 17:38 ` Steve Capper
2020-10-14 3:44 ` Anshuman Khandual
2020-10-14 7:18 ` Ard Biesheuvel
2020-10-08 15:36 ` [PATCH v2 3/4] arm64: mm: make vmemmap region a projection of the linear region Ard Biesheuvel
2020-10-13 16:52 ` Steve Capper
2020-11-10 12:55 ` Geert Uytterhoeven
2020-11-10 13:10 ` Ard Biesheuvel
2020-11-10 14:08 ` Ard Biesheuvel
2020-11-10 14:56 ` Geert Uytterhoeven
2020-11-10 15:39 ` Catalin Marinas
2020-11-10 15:42 ` Ard Biesheuvel
2020-11-10 16:14 ` Catalin Marinas
2020-11-10 16:18 ` Ard Biesheuvel
2020-10-08 15:36 ` [PATCH v2 4/4] arm64: mm: tidy up top of kernel VA space Ard Biesheuvel
2020-10-13 16:52 ` Steve Capper
2020-10-09 14:16 ` [PATCH v2 0/4] arm64: mm: optimize VA space organization for 52-bit Ard Biesheuvel
2020-10-15 20:40 ` Will Deacon
2020-11-09 18:51 ` Catalin Marinas
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=68c0ac2b-e622-ee29-138b-1415cb80becb@arm.com \
--to=steve.capper@arm.com \
--cc=Anshuman.Khandual@arm.com \
--cc=Catalin.Marinas@arm.com \
--cc=ardb@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=nd@arm.com \
--cc=will@kernel.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.