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 1/4] arm64: mm: use single quantity to represent the PA to VA translation
Date: Tue, 13 Oct 2020 16:47:28 +0000 [thread overview]
Message-ID: <DB8PR08MB49860753335265E26BA7ED7181040@DB8PR08MB4986.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <20201008153602.9467-2-ardb@kernel.org>
Hi Ard,
On 08/10/2020 16:35, Ard Biesheuvel wrote:
> On arm64, the global variable memstart_addr represents the physical
> address of PAGE_OFFSET, and so physical to virtual translations or
> vice versa used to come down to simple additions or subtractions
> involving the values of PAGE_OFFSET and memstart_addr.
>
> When support for 52-bit virtual addressing was introduced, we had to
> deal with PAGE_OFFSET potentially being outside of the region that can
> be covered by the virtual range (as the 52-bit VA capable build needs
> to be able to run on systems that are only 48-bit VA capable), and for
> this reason, another translation was introduced, and recorded in the
> global variable physvirt_offset.
>
> However, if we go back to the original definition of memstart_addr,
> i.e., the physical address of PAGE_OFFSET, it turns out that there is
> no need for two separate translations: instead, we can simply subtract
> the size of the unaddressable VA space from memstart_addr to make the
> available physical memory appear in the 48-bit addressable VA region.
>
> This simplifies things, but also fixes a bug on KASLR builds, which
> may update memstart_addr later on in arm64_memblock_init(), but fails
> to update vmemmap and physvirt_offset accordingly.
>
Apologies, I didn't spot that before.
> Fixes: 5383cc6efed13 ("arm64: mm: Introduce vabits_actual")
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Thanks for this. It is much better to modify memstart_addr rather than introducing needless complexity.
Reviewed-by: Steve Capper <steve.capper@arm.com>
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:49 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 [this message]
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
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=DB8PR08MB49860753335265E26BA7ED7181040@DB8PR08MB4986.eurprd08.prod.outlook.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.