lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXGVNWrm6=sWixL3PiXr1DQN_buvm1YxQW2+zALgd3b-hA@mail.gmail.com>
Date: Wed, 27 Mar 2024 17:57:55 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Ryan Roberts <ryan.roberts@....com>
Cc: Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, 
	Mark Rutland <mark.rutland@....com>, David Hildenbrand <david@...hat.com>, 
	Donald Dutile <ddutile@...hat.com>, Eric Chanudet <echanude@...hat.com>, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 0/3] Speed up boot with faster linear map creation

On Wed, 27 Mar 2024 at 17:01, Ryan Roberts <ryan.roberts@....com> wrote:
>
> On 27/03/2024 13:36, Ard Biesheuvel wrote:
> > On Wed, 27 Mar 2024 at 12:43, Ryan Roberts <ryan.roberts@....com> wrote:
> >>
> >> On 27/03/2024 10:09, Ard Biesheuvel wrote:
..
> >
> > I think a mix of the fixmap approach with a 1:1 map could work here:
> > - use TTBR0 to create a temp 1:1 map of DRAM
> > - map page tables lazily as they are allocated but using a coarse mapping
> > - avoid all TLB maintenance except at the end when tearing down the 1:1 mapping.
>
> Yes that could work I think. So to make sure I've understood:
>
>  - create a 1:1 map for all of DRAM using block and cont mappings where possible
>      - use memblock_phys_alloc_*() to allocate pgtable memory
>      - access via fixmap (should be minimal due to block mappings)

Yes but you'd only need the fixmap for pages that are not in the 1:1
map yet, so after an initial ramp up you wouldn't need it at all,
assuming locality of memblock allocations and the use of PMD mappings.
The only tricky thing here is ensuring that we are not mapping memory
that we shouldn't be touching.

>  - install it in TTBR0
>  - create all the swapper mappings as normal (no block or cont mappings)
>      - use memblock_phys_alloc_*() to alloc pgtable memory
>      - phys address is also virtual address due to installed 1:1 map
>  - Remove 1:1 map from TTBR0
>  - memblock_phys_free() all the memory associated with 1:1 map
>

Indeed.

> That sounds doable on top of the first 2 patches in this series - I'll have a
> crack. The only missing piece is depth-first 1:1 map traversal to free the
> tables. I'm guessing something already exists that I can repurpose?
>

Not that I am aware of, but that doesn't sound too complicated.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ