From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: mm: clear SCTLR.HA instead of setting it for LPAE
Date: Tue, 23 Sep 2014 17:23:02 +0100 [thread overview]
Message-ID: <20140923162302.GL28608@arm.com> (raw)
In-Reply-To: <20140923161628.GD6858@e104818-lin.cambridge.arm.com>
On Tue, Sep 23, 2014 at 05:16:29PM +0100, Catalin Marinas wrote:
> On Mon, Sep 22, 2014 at 04:02:17PM +0100, Will Deacon wrote:
> > SCTLR.HA (hardware access flag) is deprecated, not actually implemented
> > by any CPUs
>
> That I agree.
>
> > and would probably break Linux if it was (since we don't use
> > atomics when accessing page table entries).
>
> But not here. The ARMv7 ARM states:
>
> Any implementation of hardware management of the Access flag must
> ensure that any software changes to the translation table are not
> overwritten. The architecture does not require software that changes
> translation table entries to use interlocked operations. The hardware
> management mechanisms for the Access flag must prevent any loss of
> data written to translation table entries that might occur when, for
> example, a write by another processor occurs between the read and
> write phases of a translation table walk that updates the Access flag.
>
> So basically you should not be required to change the OS for atomic
> accesses to the page table entries. There is indeed a chance that the OS
> would inadvertently clear the AF bit but that's only affecting the
> statistics a bit.
Well, that explains why nobody managed to implement this in hardware! I'll
remove that part from the commit message.
> > Furthermore, it can confuse cr_alignment checks where the whole value
> > of SCTLR is compared against the value sitting in the hardware, since
> > the bit is actually RAZ/WI and will not match the saved cr_alignment
> > value.
>
> Is this the right fix for cr_alignment? What if we get other bits in the
> future which are RAZ/WI on ARMv7 and RW on 32-bit ARMv8?
In that case, we'd need to adjust our masks to avoid setting RAZ/WI bits.
This will only be a problem where we were trying to use a feature that was
removed, so it's a useful exercise to go through anyway (an alternative is
to read back the value and see what stuck, but that feels fragile).
Will
prev parent reply other threads:[~2014-09-23 16:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-22 15:02 [PATCH] ARM: mm: clear SCTLR.HA instead of setting it for LPAE Will Deacon
2014-09-23 16:16 ` Catalin Marinas
2014-09-23 16:23 ` Will Deacon [this message]
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=20140923162302.GL28608@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 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.