Linux-ARM-Kernel Archive on
 help / color / Atom feed
From: Bhupesh Sharma <>
To: Suzuki K Poulose <>,
Subject: Re: [PATCH 1/2] arm64: Expose address bits (physical/virtual) via cpuinfo
Date: Thu, 31 Jan 2019 01:18:05 +0530
Message-ID: <> (raw)
In-Reply-To: <>

Hi Suzuki,

Thanks for your review.

On 01/29/2019 03:39 PM, Suzuki K Poulose wrote:
> Hi Bupesh
> On 28/01/2019 20:57, Bhupesh Sharma wrote:
>> With ARMv8.2-LVA and LPA architecture extensions, arm64 hardware which
>> supports these extensions can support upto 52-bit virtual and 52-bit
>> physical addresses respectively.
>> Since at the moment we enable the support of these extensions via CONFIG
>> flags, e.g.
>>   - LPA via CONFIG_ARM64_PA_BITS_52, and
>> The easiest way a user can determine the physical/virtual
>> addresses supported on the hardware, is via the '/proc/cpuinfo'
>> interface.
> Why do we need this information ?

Sorry for the delay in reply, but I wanted to collect as much 
information from our test teams as possible before replying to this thread.

So here is brief list of reasons, as to why we need this information in 

1. This information is useful for a non-expert user, using Linux 
distributions (like Fedora) on different arm64 platforms. The default 
configuration (.config) will be the same for a distribution flavor and 
is supposed to work fine on all underlying arm64 platforms.

a). Now some of these underlying platforms may support ARMv8-8.2 
extension while others don't.

b). Users performing performance bench-marking on these platforms run 
benchmarks with different page-sizes and address ranges.

c). Right now they have no way to know, about the underlying VARange and 
PARange values other than reading the config file and search for the flags.

For e.g. lets consider the 'pg-table_tests' (See - 
<>), which is used to test 
and verify 5-level page table behavior on x86_64 Linux. It requires 
determining if 5-level page tables are fully supported, for which it 
uses either 'Intel 'la57' cpu flag' in:

$ cat /proc/cpuinfo', or

$ grep CONFIG_X86_5LEVEL /boot/config-$(uname -r)

This test suite is easily modifiable for verifying 52-bit ARMv8.2-LVA 

d). Now when running the above suite and sharing results, it might be 
that the .config file is not available or even in the case it is 
available the CONFIG flag settings in .config file are not intuitive to 
a non-expert user for arm64 (the example below is of 64K page size, 
48-bit kernel VA, 52-bit User space VA and 52-bit PA):


Compare it with a single CONFIG_X86_5LEVEL=y config item for x86_64.

Also the cpu flag in '/proc/cpuinfo' may not hold any descriptive value 
for ARMv8.2 hardware.

2. So, its much easier in above cases to see and quote the output of '$ 
cat /proc/cpuinfo' instead, for example:

$ cat /proc/cpuinfo

processor	: 31
CPU architecture: 8
address sizes	: 52 bits physical, 48 bits virtual

> Btw, this keeps coming up all the time and the answer to this approach is
> always no. We cannot break the "unwritten" ABI of /proc/cpuinfo, again.
> See :

I understand your point, but from a user-space/command-line p-o-v we 
would ideally want an arm64 server to support most features that are 
already available on a x86_64 server (I guess that was the whole point 
of the SBSA server specifications - we want all arm64 servers to look 
and feel the same way in terms of user-experience).

Also right now there is an absence of a standard ABI between the 
user-space and kernel for exporting this information to the user-space, 
with two exceptions:

1. For vmcoreinfo specific user-space utilities (like makedumpfile and 
crash) I have proposed a couple of CONFIG flags to be added to the 
vmcoreinfo, so that user-space utilities can use the same (See 
for details).

2. For other user-space utilities (especially those which make a 'mmap' 
call and pass an address hint to the get the kernel to provide a high 
address), I can see only two methods to determine the underlying kernel 

a). Read the CONFIG flags from .config (as I captured some paragraphs 
above), or

b). In absence of .config file on the system, read the system ID 
registers like 'ID_AA64MMFR0_EL1' and 'ID_AA64MMFR2_EL1' (which PATCH 
2/2 of this series tries to enable from kernel side) and then make a 
decision on whether to pass a hint to 'mmap'.

It might be that I am missing other standard ABI mechanisms. If so, 
please point me to the same.


linux-arm-kernel mailing list

  reply index

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-28 20:57 [PATCH 0/2] arm64: Expose physical and virtual address capabilities to user-space Bhupesh Sharma
2019-01-28 20:57 ` [PATCH 1/2] arm64: Expose address bits (physical/virtual) via cpuinfo Bhupesh Sharma
2019-01-29 10:09   ` Suzuki K Poulose
2019-01-30 19:48     ` Bhupesh Sharma [this message]
2019-02-04 16:54       ` James Morse
2019-01-28 20:57 ` [PATCH 2/2] arm64: Expose PARange via ID_AA64MMFR0_EL1 and VARange via ID_AA64MMFR2_EL1 Bhupesh Sharma
2019-01-29 10:14   ` Suzuki K Poulose
2019-01-30 20:27     ` Bhupesh Sharma

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ARM-Kernel Archive on

Archives are clonable:
	git clone --mirror linux-arm-kernel/git/0.git
	git clone --mirror linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ \
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone