Detect presence of LPAE when not running an LPAE kernel?

Detect presence of LPAE when not running an LPAE kernel?

[Ian Campbell]

Is this possible?

The Features field of /proc/cpuinfo only appears to reflect the presence
of LPAE if CONFIG_LPAE is actually on in the running kernel.

The reason I care is so that distro installers can ship a generic kernel
but select LPAE for the running system when appropriate.

On x86 for example I would check /proc/cpuinfo:flags which contains the
CPU features, regardless of whether they are currently enabled.

Is there any equivalent on ARM?

Ian.

Detect presence of LPAE when not running an LPAE kernel?

[Russell King - ARM Linux]

On Thu, Oct 03, 2013 at 08:43:23PM +0100, Ian Campbell wrote:
> Is this possible?
> 
> The Features field of /proc/cpuinfo only appears to reflect the presence
> of LPAE if CONFIG_LPAE is actually on in the running kernel.
> 
> The reason I care is so that distro installers can ship a generic kernel
> but select LPAE for the running system when appropriate.
> 
> On x86 for example I would check /proc/cpuinfo:flags which contains the
> CPU features, regardless of whether they are currently enabled.
> 
> Is there any equivalent on ARM?

Perversely, LPAE in there has nothing to do with LPAE being used by the
kernel.  It's more to do with the presence of the double-word load/store
exclusive.

It went through lots of discussions about what to call this, whether it
was "ATOMICD" (which is very perverse and vague) or LPAE (which is what
it was keyed off of).

Now, this LPAE flag is present whether or not the kernel has been built
with CONFIG_LPAE enabled or not.  That's because its not about LPAE
really, it's about those load/store exclusive instructions.

Now, this isn't applied to all flags: we hide certain CPU facilities
when the kernel support is missing, because the instructions can't be
used without kernel support being present.  For instance, if the VFP
support code is not present, support for VFP instructions will be
hidden (and the instructions disabled) because there's nothing to
context-switch the VFP state and stop one thread interfering with
another.

Detect presence of LPAE when not running an LPAE kernel?

[Ian Campbell]

On Thu, 2013-10-03 at 21:07 +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 03, 2013 at 08:43:23PM +0100, Ian Campbell wrote:
> > Is this possible?
> > 
> > The Features field of /proc/cpuinfo only appears to reflect the presence
> > of LPAE if CONFIG_LPAE is actually on in the running kernel.
> > 
> > The reason I care is so that distro installers can ship a generic kernel
> > but select LPAE for the running system when appropriate.
> > 
> > On x86 for example I would check /proc/cpuinfo:flags which contains the
> > CPU features, regardless of whether they are currently enabled.
> > 
> > Is there any equivalent on ARM?
> 
> Perversely, LPAE in there has nothing to do with LPAE being used by the
> kernel.  It's more to do with the presence of the double-word load/store
> exclusive.

Ah, and I'm running 3.10 whereas this was added to 3.11-rc1.

> It went through lots of discussions about what to call this, whether it
> was "ATOMICD" (which is very perverse and vague) or LPAE (which is what
> it was keyed off of).
> 
> Now, this LPAE flag is present whether or not the kernel has been built
> with CONFIG_LPAE enabled or not.  That's because its not about LPAE
> really, it's about those load/store exclusive instructions.

So would it be sensible for userspace to use the presence of this lpae
flag from 3.11 onwards to indicate the possibility of running lpae? It
sounds like it might be theoretically a bit dodgy but in actual fact
fine in reality?

Should/do we expose the actual CPU LPAE capability somewhere?

> Now, this isn't applied to all flags: we hide certain CPU facilities
> when the kernel support is missing, because the instructions can't be
> used without kernel support being present.  For instance, if the VFP
> support code is not present, support for VFP instructions will be
> hidden (and the instructions disabled) because there's nothing to
> context-switch the VFP state and stop one thread interfering with
> another.

That's completely reasonable.

Ian.

Detect presence of LPAE when not running an LPAE kernel?

[Will Deacon]

On Fri, Oct 04, 2013 at 08:15:08AM +0100, Ian Campbell wrote:
> On Thu, 2013-10-03 at 21:07 +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 03, 2013 at 08:43:23PM +0100, Ian Campbell wrote:
> > > Is this possible?
> > > 
> > > The Features field of /proc/cpuinfo only appears to reflect the presence
> > > of LPAE if CONFIG_LPAE is actually on in the running kernel.
> > > 
> > > The reason I care is so that distro installers can ship a generic kernel
> > > but select LPAE for the running system when appropriate.
> > > 
> > > On x86 for example I would check /proc/cpuinfo:flags which contains the
> > > CPU features, regardless of whether they are currently enabled.
> > > 
> > > Is there any equivalent on ARM?
> > 
> > Perversely, LPAE in there has nothing to do with LPAE being used by the
> > kernel.  It's more to do with the presence of the double-word load/store
> > exclusive.
> 
> Ah, and I'm running 3.10 whereas this was added to 3.11-rc1.

Unless my memory is broken, if you see this HWCAP in a mainline kernel it
has always meant "the CPU you are running on is capable of LPAE". I don't
remember any dependency on CONFIG_LPAE.

> Should/do we expose the actual CPU LPAE capability somewhere?

That's the whole point of the HWCAP.

Are you sure your 3.10 hasn't got some extra magic?

Will

Detect presence of LPAE when not running an LPAE kernel?

[Ian Campbell]

On Fri, 2013-10-04 at 17:09 +0100, Will Deacon wrote:
> On Fri, Oct 04, 2013 at 08:15:08AM +0100, Ian Campbell wrote:
> > On Thu, 2013-10-03 at 21:07 +0100, Russell King - ARM Linux wrote:
> > > On Thu, Oct 03, 2013 at 08:43:23PM +0100, Ian Campbell wrote:
> > > > Is this possible?
> > > > 
> > > > The Features field of /proc/cpuinfo only appears to reflect the presence
> > > > of LPAE if CONFIG_LPAE is actually on in the running kernel.
> > > > 
> > > > The reason I care is so that distro installers can ship a generic kernel
> > > > but select LPAE for the running system when appropriate.
> > > > 
> > > > On x86 for example I would check /proc/cpuinfo:flags which contains the
> > > > CPU features, regardless of whether they are currently enabled.
> > > > 
> > > > Is there any equivalent on ARM?
> > > 
> > > Perversely, LPAE in there has nothing to do with LPAE being used by the
> > > kernel.  It's more to do with the presence of the double-word load/store
> > > exclusive.
> > 
> > Ah, and I'm running 3.10 whereas this was added to 3.11-rc1.
> 
> Unless my memory is broken, if you see this HWCAP in a mainline kernel it
> has always meant "the CPU you are running on is capable of LPAE". I don't
> remember any dependency on CONFIG_LPAE.

I was just confused by it not appearing in 3.10 and assumed it was a
dependency on CONFIG_LPAE when in reality the hwcap just wasn't added
until 3.11-rc1.

> > Should/do we expose the actual CPU LPAE capability somewhere?
> 
> That's the whole point of the HWCAP.

Russell was saying it actually related to the presence of strd/ldrd, how
tightly is that tied to the presence of LPAE in theory? In practise it
seems closely related...

> Are you sure your 3.10 hasn't got some extra magic?

Yep ;-)

Ian.

Detect presence of LPAE when not running an LPAE kernel?

[Will Deacon]

On Fri, Oct 04, 2013 at 05:23:22PM +0100, Ian Campbell wrote:
> On Fri, 2013-10-04 at 17:09 +0100, Will Deacon wrote:
> > On Fri, Oct 04, 2013 at 08:15:08AM +0100, Ian Campbell wrote:
> > > Should/do we expose the actual CPU LPAE capability somewhere?
> > 
> > That's the whole point of the HWCAP.
> 
> Russell was saying it actually related to the presence of strd/ldrd, how
> tightly is that tied to the presence of LPAE in theory? In practise it
> seems closely related...

Take a gander at the code: we're checking the VMSA version in one of the
MMFR registers. LPAE implies atomic ldrd/strd, so that's what this is all
about (and why it ended up being called "lpae").

In short, this HWCAP does exactly what you want.

Will

Detect presence of LPAE when not running an LPAE kernel?

[Ian Campbell]

On Fri, 2013-10-04 at 17:26 +0100, Will Deacon wrote:
> On Fri, Oct 04, 2013 at 05:23:22PM +0100, Ian Campbell wrote:
> > On Fri, 2013-10-04 at 17:09 +0100, Will Deacon wrote:
> > > On Fri, Oct 04, 2013 at 08:15:08AM +0100, Ian Campbell wrote:
> > > > Should/do we expose the actual CPU LPAE capability somewhere?
> > > 
> > > That's the whole point of the HWCAP.
> > 
> > Russell was saying it actually related to the presence of strd/ldrd, how
> > tightly is that tied to the presence of LPAE in theory? In practise it
> > seems closely related...
> 
> Take a gander at the code: we're checking the VMSA version in one of the
> MMFR registers. LPAE implies atomic ldrd/strd, so that's what this is all
> about (and why it ended up being called "lpae").

Yes, I see what you mean (check for VMSA >= 5, which is "adds support
for the Long-descriptor translation table format").

You can determine the presence of ldrd/strd from this but that's a bit
of a red herring in the context. I thought Russell was saying the kernel
was checking for a ldrd/strd bit in some feature register and inferring
the lpae flag in /proc/cpuinfo from that, which was why I was concerned.

> In short, this HWCAP does exactly what you want.

Agreed, thanks.

Ian