From: Marc Zyngier <maz@kernel.org>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Kees Cook <keescook@chromium.org>
Subject: Re: [RFC PATCH 7/8] arm64/mm: Use reduced VA sizes (36/39/42 bits) only for user space
Date: Wed, 30 Oct 2024 12:44:38 +0000 [thread overview]
Message-ID: <861pzx3gll.wl-maz@kernel.org> (raw)
In-Reply-To: <20241030101803.2037606-17-ardb+git@google.com>
On Wed, 30 Oct 2024 10:18:11 +0000,
Ard Biesheuvel <ardb+git@google.com> wrote:
>
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The advantage of a reduced virtual address space size is its impact on
> the number of translation levels, which affects TLB pressure. The
> working set of translations covering the kernel side is negligible
> compared to user space, where each process has its own set of page
> tables, and so most of the same benefit can be obtained by reducing the
> VA size only for user space.
>
> As a preparatory step towards implementing this, drop all the reduced VA
> space sizes in Kconfig, and replace it with a configurable userland VA
> space size that is reflected in TASK_SIZE. This will be taken advantage
> of in a subsequent patch to actually reduce the number of translations
> used by the MMU for translating user space virtual addresses.
I think this may have an impact on KVM's walking of the userspace page
tables to determine whether we are trying to install a block mapping,
which assumes that the start level and the number of VA bits are the
same as the kernel (see get_user_mapping_size()).
Probably nothing too complicated, but something to look into.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-10-30 12:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-30 10:18 [RFC PATCH 0/8] arm64: Simplify VA space configurations Ard Biesheuvel
2024-10-30 10:18 ` [RFC PATCH 1/8] arm64: Kconfig: force ARM64_PAN=y when enabling TTBR0 sw PAN Ard Biesheuvel
2024-10-30 10:18 ` [RFC PATCH 2/8] arm64: Kconfig: fix ARCH_MMAP_RND_BITS_MAX for 52-bit virtual addressing Ard Biesheuvel
2024-10-30 10:18 ` [RFC PATCH 3/8] arm64: Kconfig: eliminate 64k/48-bit VA combination Ard Biesheuvel
2024-10-30 10:18 ` [RFC PATCH 4/8] arm64: Kconfig: eliminate 4k/48-bit " Ard Biesheuvel
2024-10-30 10:18 ` [RFC PATCH 5/8] arm64/Kconfig: Drop support for 47-bit virtual addressing Ard Biesheuvel
2024-10-30 10:18 ` [RFC PATCH 6/8] arm64/Kconfig: Drop support for 48-bit " Ard Biesheuvel
2024-10-30 10:18 ` [RFC PATCH 7/8] arm64/mm: Use reduced VA sizes (36/39/42 bits) only for user space Ard Biesheuvel
2024-10-30 12:44 ` Marc Zyngier [this message]
2024-10-30 13:25 ` Ard Biesheuvel
2024-10-30 10:18 ` [RFC PATCH 8/8] arm64/mm: Account for reduced VA sizes in T0SZ and skip the levels 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=861pzx3gll.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=ryan.roberts@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.