From: jeremy.linton@arm.com (Jeremy Linton)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/2] arm64: Mark kernel page ranges contiguous
Date: Thu, 25 Feb 2016 14:46:54 -0600 [thread overview]
Message-ID: <56CF683D.30003@arm.com> (raw)
In-Reply-To: <20160225161630.GB16546@arm.com>
On 02/25/2016 10:16 AM, Will Deacon wrote:
> On Fri, Feb 19, 2016 at 11:46:23AM -0600, Jeremy Linton wrote:
(trimming)
>> +static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
>> +{
>> + int i;
>> +
>> + pte -= CONT_RANGE_OFFSET(addr);
>> + for (i = 0; i < CONT_PTES; i++) {
>> + if (pte_cont(*pte))
>> + set_pte(pte, pte_mknoncont(*pte));
>> + pte++;
>> + }
>> + flush_tlb_all();
>
> Do you still need this invalidation? I thought the table weren't even
> live at this point?
Well it continues to match the calls in alloc_init_p*.
I guess the worry is the extra flush that happens at
create_mapping_late(), if mapping ranges aren't cont aligned? (because
the loop won't actually be doing any set_pte's)
If this and the alloc_init_p* flushes are to be removed, there should
probably be a way to detect any cases where the splits are happening
after the tables have been activated. This might be a little less
straightforward given efi_create_mapping().
>
>> +}
>> +
>> +/*
>> + * Given a range of PTEs set the pfn and provided page protection flags
>> + */
>> +static void __populate_init_pte(pte_t *pte, unsigned long addr,
>> + unsigned long end, phys_addr_t phys,
>> + pgprot_t prot)
>> +{
>> + unsigned long pfn = __phys_to_pfn(phys);
>> +
>> + do {
>> + /* clear all the bits except the pfn, then apply the prot */
>> + set_pte(pte, pfn_pte(pfn, prot));
>> + pte++;
>> + pfn++;
>> + addr += PAGE_SIZE;
>> + } while (addr != end);
>> +}
>> +
(trimming)
>> +
>> do {
>> - set_pte(pte, pfn_pte(pfn, prot));
>> - pfn++;
>> - } while (pte++, addr += PAGE_SIZE, addr != end);
>> + next = min(end, (addr + CONT_SIZE) & CONT_MASK);
>> + if (((addr | next | phys) & ~CONT_MASK) == 0) {
>> + /* a block of CONT_PTES */
>> + __populate_init_pte(pte, addr, next, phys,
>> + prot | __pgprot(PTE_CONT));
>> + } else {
>> + /*
>> + * If the range being split is already inside of a
>> + * contiguous range but this PTE isn't going to be
>> + * contiguous, then we want to unmark the adjacent
>> + * ranges, then update the portion of the range we
>> + * are interested in.
>> + */
>> + clear_cont_pte_range(pte, addr);
>> + __populate_init_pte(pte, addr, next, phys, prot);
>
> I don't understand the comment or the code here... the splitting is now
> done seperately, and I can't think of a scenario where you need to clear
> the cont hint explicitly for adjacent ptes.
My understanding is that splitting is initially running this code path
(via map_kernel_chunk, then again via create_mapping_late where splits
won't happen). So, split_pmd() is creating cont ranges. When the ranges
aren't sufficiently aligned then this is wiping out the cont mapping
immediately after their creation.
next prev parent reply other threads:[~2016-02-25 20:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-19 17:46 [PATCH v3 0/2] flag contiguous PTEs in linear mapping Jeremy Linton
2016-02-19 17:46 ` [PATCH v3 1/2] arm64: mm: Enable CONT_SIZE aligned sections for 64k page kernels Jeremy Linton
2016-02-19 17:46 ` [PATCH v3 2/2] arm64: Mark kernel page ranges contiguous Jeremy Linton
2016-02-22 10:28 ` Ard Biesheuvel
2016-02-22 15:39 ` Jeremy Linton
2016-02-25 16:16 ` Will Deacon
2016-02-25 20:46 ` Jeremy Linton [this message]
2016-02-26 17:28 ` Will Deacon
2016-03-16 18:20 ` 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=56CF683D.30003@arm.com \
--to=jeremy.linton@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.