linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP
Date: Thu, 17 Jul 2014 15:27:20 +0100	[thread overview]
Message-ID: <20140717142720.GM21153@arm.com> (raw)
In-Reply-To: <20140717131224.GW21766@n2100.arm.linux.org.uk>

On Thu, Jul 17, 2014 at 02:12:24PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 17, 2014 at 02:39:42PM +0200, Arnd Bergmann wrote:
> > On Thursday 17 July 2014 09:33:42 Russell King - ARM Linux wrote:
> > > No - the problem is that we're running from the page table in question
> > > with global mappings, and we need to switch all these mappings, including
> > > the ones we're currently using to execute from.
> > > 
> > > We can't even create a new page table and switch to it because the
> > > mappings in question are global mappings.
> > > 
> > > The only way to do that safely from an architectural point of view would
> > > be to turn the MMU off, and drop back to assembly code to change the
> > > page tables, and re-enable the MMU.  For something as obscure as Marvell's
> > > coherency stuff, that's not something I want to see in core code.
> > 
> > Is this different from what we do in the LPAE version of
> > early_paging_init()? That code already adjusts all the page
> > table entries on a per-platform setting and should be very
> > easy to extend for a modified procinfo->__cpu_mm_mmu_flags,
> > and possibly able to extend for traditional (non-LPAE)
> > page tables without a lot of duplication.
> 
> I'm going to have to profess no knowledge of how the LPAE stuff works.
> LPAE is something I can't run, and something that I was not involved
> in its creation.  Therefore, I know very little about it and zero
> experience thereof.
> 
> From a glance over that function, I think that is unsafe for all the
> reasons I've stated.  However, I'll pass this over to Will Deacon
> to comment further on.

Just an FYI, but I've had to check internally to clarify the behaviour
around TLB conflict aborts. We're changing live page tables here, but the
*only* thing to differ is the output address, which I would hope is ok but
need to check to be sure.

The ARM ARM recommends always going via an invalid mapping, but that's not
always the most practical thing to do.

Will

  reply	other threads:[~2014-07-17 14:27 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-02 16:21 [PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP Thomas Petazzoni
2014-07-02 16:21 ` [PATCH 1/3] ARM: mvebu: make the coherency_ll.S functions work with no coherency fabric Thomas Petazzoni
2014-07-02 16:21 ` [PATCH 2/3] ARM: mvebu: disable I/O coherency on non-SMP situations on Armada 370/XP Thomas Petazzoni
2014-07-02 16:21 ` [PATCH 3/3] ARM: mvebu: add missing of_node_put() call in coherency.c Thomas Petazzoni
2014-07-02 16:27 ` [PATCH 0/3] ARM: mvebu: disable I/O coherency on !SMP Andrew Lunn
2014-07-02 16:41 ` Russell King - ARM Linux
2014-07-02 17:18   ` Thomas Petazzoni
2014-07-02 17:58     ` Russell King - ARM Linux
2014-07-02 20:28       ` Thomas Petazzoni
2014-07-02 21:33         ` Russell King - ARM Linux
2014-07-02 21:50           ` Thomas Petazzoni
2014-07-17  8:24   ` Thomas Petazzoni
2014-07-17  8:33     ` Russell King - ARM Linux
2014-07-17  8:45       ` Thomas Petazzoni
2014-07-17 10:27         ` Russell King - ARM Linux
2014-07-17 10:16       ` Russell King - ARM Linux
2014-07-17 12:39       ` Arnd Bergmann
2014-07-17 13:12         ` Russell King - ARM Linux
2014-07-17 14:27           ` Will Deacon [this message]
2014-07-17 14:40             ` Arnd Bergmann
2014-07-17 15:34               ` Russell King - ARM Linux
2014-07-17 15:53                 ` Arnd Bergmann
2014-07-17 16:04                   ` Santosh Shilimkar
2014-07-17 16:10                     ` Russell King - ARM Linux
2014-07-17 16:18                       ` Santosh Shilimkar
2014-07-28 17:46             ` Will Deacon

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=20140717142720.GM21153@arm.com \
    --to=will.deacon@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 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).