[PATCH 14/14] ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions

[Will Deacon]

On Mon, May 20, 2013 at 04:11:58PM +0100, Catalin Marinas wrote:
> On Mon, May 20, 2013 at 03:24:59PM +0100, Will Deacon wrote:
> > On Mon, May 20, 2013 at 03:18:09PM +0100, Catalin Marinas wrote:
> > > As I mentioned in the past, I don't agree with exposing the "LPAE"
> > > feature to user-space, it's not a feature that user space should care
> > > about. An atomic double hwcap is better and you can even make this per
> > > CPU via __v7_proc.
> > 
> > I don't buy the argument that this could be per-CPU: doubleword atomicity
> > requires support in the whole system -- not just in the CPU. The only way we
> > can rely on it, is by guarantees made in the architecture, which are made
> > as part of LPAE.
> 
> Well, you know that for A7/A15 you have this feature as they support
> LPAE. You can have it as a generic LPAE test (only that the ARM ARM
> isn't entirely clear here, so for people asking in the future we could
> say it's a feature of the A7/A15/etc.)

No, as far as Linux is concerned, it's a feature of any system claiming to
have support for LPAE. Given that we allocate page tables using our usual
allocators, all memory that we map as normal must be capable of doubleword
atomics. We make use of this in our atomic64_{read,set} implementations.

> > If this just boils down to a naming issue, thn I'm happy to change it, but
> > we *are* reporting whether LPAE is supported and I can't think of a better
> > name than that.
> 
> Given that the ARM ARM isn't clear (though this is the case on the
> actual implementations), user space may not necessarily assume that
> LPAE==atomic doubles. That's why I think reporting the actual atomic
> feature is better.

The ARM ARM isn't too bad: it's just avoiding mandating 64-bit-wide paths
around the entire SoC (and I've checked this with the architects). The only
way we can probe this feature is using the MMFR0 and checking if LPAE is
supported, and that's exactly what userspace will need to rely on. We can
change the name, but the probe code will remain the same so I'm not sure it
makes anything clearer. We had "atomicd" originally, but that sounds like a
techno band.

Will