From: wmills@ti.com (William Mills)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v2 1/4] ARM: mm: add early page table attribute modification ability
Date: Mon, 6 Jun 2016 08:31:53 -0400 [thread overview]
Message-ID: <57556D39.7050701@ti.com> (raw)
In-Reply-To: <20160606121812.GK1041@n2100.armlinux.org.uk>
On 06/06/2016 08:18 AM, Russell King - ARM Linux wrote:
> On Sun, Jun 05, 2016 at 11:20:26PM -0400, Bill Mills wrote:
>> Allow early-init to specify modifications to be made to the boot time page
>> table. Any modifications specified will be done with MMU off at the same
>> time that any Phy<->Virt fixup is done.
>
> I think this is rather over-engineered - do we need to support multiple
> different fixups to the page tables like this?
Yes I was expecting this comment but thought I would give you the choice. :)
>
> Given how this has grown, I think it would be better to duplicate the
> existing swapper_pg_dir, modify the new copy, and then have the
> pv-fixup-asm code merely copy the new to the old with the MMU off.
> That way, the only two things that the assembly code has to do is to
> deal with the page table update, and updating the TTBR registers.
> Most of the complexity can then be kept in the C code.
>
I really like this. I can just do the outer shared fixup and not worry
about a generalized mechanism. *If* someone needs to do another fixup
they can just code it in C.
The new patch #1 will just rework the PV_FIXUP for the new asm/C split.
You want the off-line table to copy over the early table in place w/ MMU
off, correct? (Not update the HW to point to a new spot.)
> I think we also need to modify the TTBCR to match the sharability of
> memory - currently, TTB walks will be inner sharable, but my
> understanding is that if we switch memory to be outer sharable, we
> also need to update the TTB walks to match.
>
Good point, Thanks. I don't think our internal hack has been doing that.
WARNING: multiple messages have this Message-ID (diff)
From: William Mills <wmills@ti.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: <mark.rutland@arm.com>, <t-kristo@ti.com>, <ssantosh@kernel.org>,
<catalin.marinas@arm.com>, <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <r-woodruff2@ti.com>
Subject: Re: [RFC v2 1/4] ARM: mm: add early page table attribute modification ability
Date: Mon, 6 Jun 2016 08:31:53 -0400 [thread overview]
Message-ID: <57556D39.7050701@ti.com> (raw)
In-Reply-To: <20160606121812.GK1041@n2100.armlinux.org.uk>
On 06/06/2016 08:18 AM, Russell King - ARM Linux wrote:
> On Sun, Jun 05, 2016 at 11:20:26PM -0400, Bill Mills wrote:
>> Allow early-init to specify modifications to be made to the boot time page
>> table. Any modifications specified will be done with MMU off at the same
>> time that any Phy<->Virt fixup is done.
>
> I think this is rather over-engineered - do we need to support multiple
> different fixups to the page tables like this?
Yes I was expecting this comment but thought I would give you the choice. :)
>
> Given how this has grown, I think it would be better to duplicate the
> existing swapper_pg_dir, modify the new copy, and then have the
> pv-fixup-asm code merely copy the new to the old with the MMU off.
> That way, the only two things that the assembly code has to do is to
> deal with the page table update, and updating the TTBR registers.
> Most of the complexity can then be kept in the C code.
>
I really like this. I can just do the outer shared fixup and not worry
about a generalized mechanism. *If* someone needs to do another fixup
they can just code it in C.
The new patch #1 will just rework the PV_FIXUP for the new asm/C split.
You want the off-line table to copy over the early table in place w/ MMU
off, correct? (Not update the HW to point to a new spot.)
> I think we also need to modify the TTBCR to match the sharability of
> memory - currently, TTB walks will be inner sharable, but my
> understanding is that if we switch memory to be outer sharable, we
> also need to update the TTB walks to match.
>
Good point, Thanks. I don't think our internal hack has been doing that.
next prev parent reply other threads:[~2016-06-06 12:31 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-06 3:20 [RFC v2 0/4] ARM LPAE Outer Shared v2 Bill Mills
2016-06-06 3:20 ` Bill Mills
2016-06-06 3:20 ` [RFC v2 1/4] ARM: mm: add early page table attribute modification ability Bill Mills
2016-06-06 3:20 ` Bill Mills
2016-06-06 12:18 ` Russell King - ARM Linux
2016-06-06 12:18 ` Russell King - ARM Linux
2016-06-06 12:31 ` William Mills [this message]
2016-06-06 12:31 ` William Mills
2016-06-06 3:20 ` [RFC v2 2/4] ARM: mm: Add LPAE support for outer shared Bill Mills
2016-06-06 3:20 ` Bill Mills
2016-06-06 3:20 ` [RFC v2 3/4] ARM: mm: add inner/outer sharing value command line Bill Mills
2016-06-06 3:20 ` Bill Mills
2016-06-06 3:20 ` [RFC v2 4/4] ARM: keystone: dma-coherent with safe fallback Bill Mills
2016-06-06 3:20 ` Bill Mills
2016-06-06 8:56 ` Mark Rutland
2016-06-06 8:56 ` Mark Rutland
2016-06-06 9:09 ` Arnd Bergmann
2016-06-06 9:09 ` Arnd Bergmann
2016-06-06 11:42 ` Mark Rutland
2016-06-06 11:42 ` Mark Rutland
2016-06-06 12:37 ` Arnd Bergmann
2016-06-06 12:37 ` Arnd Bergmann
2016-06-06 12:50 ` William Mills
2016-06-06 12:50 ` William Mills
2016-06-06 12:50 ` William Mills
2016-06-06 16:18 ` Santosh Shilimkar
2016-06-06 16:18 ` Santosh Shilimkar
2016-06-06 11:43 ` Russell King - ARM Linux
2016-06-06 11:43 ` Russell King - ARM Linux
2016-06-06 11:43 ` Russell King - ARM Linux
2016-06-06 11:59 ` Mark Rutland
2016-06-06 11:59 ` Mark Rutland
2016-06-06 12:19 ` William Mills
2016-06-06 12:19 ` William Mills
2016-06-06 12:19 ` William Mills
2016-06-06 12:32 ` Russell King - ARM Linux
2016-06-06 12:32 ` Russell King - ARM Linux
2016-06-06 16:28 ` Santosh Shilimkar
2016-06-06 16:28 ` Santosh Shilimkar
2016-06-07 10:01 ` Mark Rutland
2016-06-07 10:01 ` Mark Rutland
2016-06-07 10:01 ` Mark Rutland
2016-06-07 12:32 ` Russell King - ARM Linux
2016-06-07 12:32 ` Russell King - ARM Linux
2016-06-07 12:55 ` Mark Rutland
2016-06-07 12:55 ` Mark Rutland
2016-06-07 12:55 ` Mark Rutland
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=57556D39.7050701@ti.com \
--to=wmills@ti.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.