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$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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