From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 14/14] ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions
Date: Wed, 22 May 2013 09:47:44 +0100 [thread overview]
Message-ID: <20130522084744.GD14322@arm.com> (raw)
In-Reply-To: <CAL_JsqLSC2QgMdTGtH5G_F5SYjA3Hs--jMmxBES=fqGLwapptQ@mail.gmail.com>
On Tue, May 21, 2013 at 07:48:35PM +0100, Rob Herring wrote:
> On Mon, May 20, 2013 at 9:18 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Fri, May 17, 2013 at 06:07:53PM +0100, Will Deacon wrote:
> >> CPUs implementing LPAE have atomic ldrd/strd instructions, meaning that
> >> userspace software can avoid having to use the exclusive variants of
> >> these instructions if they wish.
> >>
> >> This patch advertises the atomicity of these instructions via the
> >> hwcaps, so userspace can detect this CPU feature.
> >>
> >> Reported-by: Vladimir Danushevsky <vladimir.danushevsky@oracle.com>
> >> Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ...
> >> +
> >> + /* LPAE implies atomic ldrd/strd instructions */
> >> + vmsa = (read_cpuid_ext(CPUID_EXT_MMFR0) & 0xf) >> 0;
> >> + if (vmsa >= 5)
> >> + elf_hwcap |= HWCAP_LPAE;
> >
> > 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.
>
> How does userspace know whether to install a non-LPAE or LPAE kernel
> in a generic way?
This is a valid reason to expose LPAE to user, though elf_hwcap sounds a
bit strange.
--
Catalin
next prev parent reply other threads:[~2013-05-22 8:47 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-17 17:07 [PATCH 00/14] Random LPAE-related patches Will Deacon
2013-05-17 17:07 ` [PATCH 01/14] ARM: LPAE: use signed arithmetic for mask definitions Will Deacon
2013-05-17 17:07 ` [PATCH 02/14] ARM: LPAE: use phys_addr_t in alloc_init_pud() Will Deacon
2013-05-17 17:07 ` [PATCH 03/14] ARM: LPAE: use phys_addr_t in free_memmap() Will Deacon
2013-05-17 17:07 ` [PATCH 04/14] ARM: LPAE: use phys_addr_t for initrd location Will Deacon
2013-05-17 17:07 ` [PATCH 05/14] ARM: LPAE: use phys_addr_t in switch_mm() Will Deacon
2013-05-17 17:07 ` [PATCH 06/14] ARM: LPAE: use 64-bit accessors for TTBR registers Will Deacon
2013-05-17 17:07 ` [PATCH 07/14] ARM: LPAE: factor out T1SZ and TTBR1 computations Will Deacon
2013-05-17 17:07 ` [PATCH 08/14] ARM: LPAE: accomodate >32-bit addresses for page table base Will Deacon
2013-05-17 17:07 ` [PATCH 09/14] ARM: mm: use physical addresses in highmem sanity checks Will Deacon
2013-05-17 17:07 ` [PATCH 10/14] ARM: fix type of PHYS_PFN_OFFSET to unsigned long Will Deacon
2013-05-17 17:07 ` [PATCH 11/14] ARM: mm: cleanup checks for membank overlap with vmalloc area Will Deacon
2013-05-17 17:07 ` [PATCH 12/14] ARM: mm: clean up membank size limit checks Will Deacon
2013-05-17 17:07 ` [PATCH 13/14] ARM: lpae: fix definition of PTE_HWTABLE_PTRS Will Deacon
2013-05-17 17:07 ` [PATCH 14/14] ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions Will Deacon
2013-05-20 14:18 ` Catalin Marinas
2013-05-20 14:24 ` Will Deacon
2013-05-20 15:11 ` Catalin Marinas
2013-05-20 16:04 ` Will Deacon
2013-05-20 17:13 ` Catalin Marinas
2013-05-21 18:02 ` Will Deacon
2013-05-22 8:43 ` Catalin Marinas
2013-05-21 18:48 ` Rob Herring
2013-05-22 8:47 ` Catalin Marinas [this message]
2013-05-22 18:09 ` Will Deacon
2013-05-23 8:50 ` Catalin Marinas
2013-05-17 18:23 ` [PATCH 00/14] Random LPAE-related patches Santosh Shilimkar
2013-05-30 13:31 ` Subash Patel
2013-05-30 15:03 ` Will Deacon
2013-05-31 0:38 ` Kukjin Kim
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=20130522084744.GD14322@arm.com \
--to=catalin.marinas@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.