From: Catalin Marinas <catalin.marinas@arm.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Joey Gouly <joey.gouly@arm.com>
Subject: Re: [PATCH 2/3] arm64: mm: Handle LVA support as a CPU feature
Date: Wed, 30 Nov 2022 14:50:23 +0000 [thread overview]
Message-ID: <Y4dtr21NmIXICSg7@arm.com> (raw)
In-Reply-To: <20221115143824.2798908-3-ardb@kernel.org>
On Tue, Nov 15, 2022 at 03:38:23PM +0100, Ard Biesheuvel wrote:
> Currently, we detect CPU support for 52-bit virtual addressing (LVA)
> extremely early, before creating the kernel page tables or enabling the
> MMU. We cannot override the feature this early, and so large virtual
> addressing is always enabled on CPUs that implement support for it if
> the software support for it was enabled at build time. It also means we
> rely on non-trivial code in asm to deal with this feature.
>
> Given that both the ID map and the TTBR1 mapping of the kernel image are
> guaranteed to be 48-bit addressable, it is not actually necessary to
> enable support this early, and instead, we can model it as a CPU
> feature. That way, we can rely on code patching to get the correct
> TCR.T1SZ values programmed on secondary boot and suspend from resume.
>
> On the primary boot path, we simply enable the MMU with 48-bit virtual
> addressing initially, and update TCR.T1SZ from C code if LVA is
> supported, right before creating the kernel mapping. Given that TTBR1
> still points to reserved_pg_dir at this point, updating TCR.T1SZ should
> be safe without the need for explicit TLB maintenance.
I'm not sure we can skip the TLBI here. There's some weird rule in the
ARM ARM that if you change any of fields that may be cached in the TLB,
maintenance is needed even if the MMU is off. From the latest version
(I.a, I didn't dig into H.a),
R_VNRFW:
When a System register field is modified and that field is permitted
to be cached in a TLB, software is required to invalidate all TLB
entries that might be affected by the field, at any address
translation stage in the translation regime even if the translation
stage is disabled, using the appropriate VMID and ASID, after any
required System register synchronization.
--
Catalin
_______________________________________________
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:[~2022-11-30 14:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-15 14:38 [PATCH 0/3] arm64: mm: Model LVA support as a CPU feature Ard Biesheuvel
2022-11-15 14:38 ` [PATCH 1/3] arm64: mm: get rid of kimage_vaddr global variable Ard Biesheuvel
2022-11-30 14:50 ` Catalin Marinas
2022-11-15 14:38 ` [PATCH 2/3] arm64: mm: Handle LVA support as a CPU feature Ard Biesheuvel
2022-11-30 14:50 ` Catalin Marinas [this message]
2022-11-30 14:56 ` Ard Biesheuvel
2022-11-30 16:28 ` Catalin Marinas
2022-11-30 16:29 ` Ard Biesheuvel
2022-11-30 16:40 ` Catalin Marinas
2022-12-01 11:13 ` Mark Rutland
2022-12-01 11:22 ` Ard Biesheuvel
2022-12-01 11:48 ` Mark Rutland
2022-11-15 14:38 ` [PATCH 3/3] arm64: mm: Add feature override support for LVA and E0PD Ard Biesheuvel
2022-11-18 14:47 ` Will Deacon
2022-11-18 14:50 ` 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=Y4dtr21NmIXICSg7@arm.com \
--to=catalin.marinas@arm.com \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=joey.gouly@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@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 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).