* [PATCH 0/2] arm64: Expose physical and virtual address capabilities to user-space @ 2019-01-28 20:57 Bhupesh Sharma 2019-01-28 20:57 ` [PATCH 1/2] arm64: Expose address bits (physical/virtual) via cpuinfo Bhupesh Sharma 2019-01-28 20:57 ` [PATCH 2/2] arm64: Expose PARange via ID_AA64MMFR0_EL1 and VARange via ID_AA64MMFR2_EL1 Bhupesh Sharma 0 siblings, 2 replies; 8+ messages in thread From: Bhupesh Sharma @ 2019-01-28 20:57 UTC (permalink / raw) To: linux-arm-kernel Cc: mark.rutland, steve.capper, catalin.marinas, bhsharma, ard.biesheuvel, will.deacon, bhupesh.linux, kexec, suzuki.poulose 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 there are no clear mechanisms in user-space right now to deteremine these CONFIG flag values and also determine the PARange and VARange address values. This patchset proposes two mechanisms to provide a user/user-space application more information on the same: 1. For a non-expert user, getting an idea about the virtual/physical address capabilities on an arm64 hardware via executing: $ cat /proc/cpuinfo can be quite useful as it provides a similar mechanism as available already on x86_64. PATCH 1/2 implements the same. 2. For a more involved user/user-space application, the Appendix I: Example in 'Documentation/arm64/cpu-feature-registers.txt' is pretty useful. If we can expose the PARange and VARange values via the MRS register reads to user-space, we can use them in user-space programs as a standard ABI. I already have a 'makedumpfile' user-space example that uses the same to determine ARMv8.2-LPA support. See [0]. PATCH 2/2 implements the same. [0]. https://github.com/bhupesh-sharma/makedumpfile/blob/9d7da4aad3efe79b448f48cc3454fcae46a316d6/arch/arm64.c#L499 Bhupesh Sharma (2): arm64: Expose address bits (physical/virtual) via cpuinfo arm64: Expose PARange via ID_AA64MMFR0_EL1 and VARange via ID_AA64MMFR2_EL1 arch/arm64/include/asm/cpufeature.h | 59 ++++++++++++++++++++++++------------- arch/arm64/include/asm/sysreg.h | 19 ++++++++++++ arch/arm64/kernel/cpufeature.c | 4 +-- arch/arm64/kernel/cpuinfo.c | 4 ++- 4 files changed, 63 insertions(+), 23 deletions(-) -- 2.7.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/2] arm64: Expose address bits (physical/virtual) via cpuinfo 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 ` Bhupesh Sharma 2019-01-29 10:09 ` Suzuki K Poulose 2019-01-28 20:57 ` [PATCH 2/2] arm64: Expose PARange via ID_AA64MMFR0_EL1 and VARange via ID_AA64MMFR2_EL1 Bhupesh Sharma 1 sibling, 1 reply; 8+ messages in thread From: Bhupesh Sharma @ 2019-01-28 20:57 UTC (permalink / raw) To: linux-arm-kernel Cc: mark.rutland, steve.capper, catalin.marinas, bhsharma, ard.biesheuvel, will.deacon, bhupesh.linux, kexec, suzuki.poulose 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 - LVA via CONFIG_ARM64_FORCE_52BIT The easiest way a user can determine the physical/virtual addresses supported on the hardware, is via the '/proc/cpuinfo' interface. This patches enables the same. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> --- arch/arm64/include/asm/cpufeature.h | 59 ++++++++++++++++++++++++------------- arch/arm64/include/asm/sysreg.h | 19 ++++++++++++ arch/arm64/kernel/cpuinfo.c | 4 ++- 3 files changed, 61 insertions(+), 21 deletions(-) diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h index dfcfba725d72..2f1270ddc277 100644 --- a/arch/arm64/include/asm/cpufeature.h +++ b/arch/arm64/include/asm/cpufeature.h @@ -522,6 +522,45 @@ static inline bool system_supports_32bit_el0(void) return cpus_have_const_cap(ARM64_HAS_32BIT_EL0); } +static inline u32 id_aa64mmfr0_parange_to_phys_shift(int parange) +{ + switch (parange) { + case ID_AA64MMFR0_PARANGE_32: return PARANGE_32; + case ID_AA64MMFR0_PARANGE_36: return PARANGE_36; + case ID_AA64MMFR0_PARANGE_40: return PARANGE_40; + case ID_AA64MMFR0_PARANGE_44: return PARANGE_44; + case ID_AA64MMFR0_PARANGE_48: return PARANGE_48; + case ID_AA64MMFR0_PARANGE_52: return PARANGE_52; + /* + * A future PE could use a value unknown to the kernel. + * However, by the "D10.1.4 Principles of the ID scheme + * for fields in ID registers", ARM DDI 0487C.a, any new + * value is guaranteed to be higher than what we know already. + * As a safe limit, we return the limit supported by the kernel. + */ + default: return CONFIG_ARM64_PA_BITS; + } +} + +static inline u32 id_aa64mmfr0_pa_range_bits(void) +{ + u64 mmfr0; + + mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1); + return id_aa64mmfr0_parange_to_phys_shift(mmfr0 & 0x7); +} + +static inline u32 id_aa64mmfr2_va_range_bits(void) +{ + u64 mmfr2; + u32 val; + + mmfr2 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR2_EL1); + val = cpuid_feature_extract_unsigned_field(mmfr2, + ID_AA64MMFR2_LVA_SHIFT); + return ((val == ID_AA64MMFR2_VARANGE_52) ? VARANGE_52 : VARANGE_48); +} + static inline bool system_supports_4kb_granule(void) { u64 mmfr0; @@ -636,26 +675,6 @@ static inline void arm64_set_ssbd_mitigation(bool state) {} extern int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt); -static inline u32 id_aa64mmfr0_parange_to_phys_shift(int parange) -{ - switch (parange) { - case 0: return 32; - case 1: return 36; - case 2: return 40; - case 3: return 42; - case 4: return 44; - case 5: return 48; - case 6: return 52; - /* - * A future PE could use a value unknown to the kernel. - * However, by the "D10.1.4 Principles of the ID scheme - * for fields in ID registers", ARM DDI 0487C.a, any new - * value is guaranteed to be higher than what we know already. - * As a safe limit, we return the limit supported by the kernel. - */ - default: return CONFIG_ARM64_PA_BITS; - } -} #endif /* __ASSEMBLY__ */ #endif diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h index 72dc4c011014..70910b14b2f3 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -617,9 +617,22 @@ #define ID_AA64MMFR0_TGRAN64_SUPPORTED 0x0 #define ID_AA64MMFR0_TGRAN16_NI 0x0 #define ID_AA64MMFR0_TGRAN16_SUPPORTED 0x1 +#define ID_AA64MMFR0_PARANGE_32 0x0 +#define ID_AA64MMFR0_PARANGE_36 0x1 +#define ID_AA64MMFR0_PARANGE_40 0x2 +#define ID_AA64MMFR0_PARANGE_42 0x3 +#define ID_AA64MMFR0_PARANGE_44 0x4 #define ID_AA64MMFR0_PARANGE_48 0x5 #define ID_AA64MMFR0_PARANGE_52 0x6 +#define PARANGE_32 32 +#define PARANGE_36 36 +#define PARANGE_40 40 +#define PARANGE_42 42 +#define PARANGE_44 44 +#define PARANGE_48 48 +#define PARANGE_52 52 + #ifdef CONFIG_ARM64_PA_BITS_52 #define ID_AA64MMFR0_PARANGE_MAX ID_AA64MMFR0_PARANGE_52 #else @@ -646,6 +659,12 @@ #define ID_AA64MMFR2_UAO_SHIFT 4 #define ID_AA64MMFR2_CNP_SHIFT 0 +#define ID_AA64MMFR2_VARANGE_48 0x0 +#define ID_AA64MMFR2_VARANGE_52 0x1 + +#define VARANGE_48 48 +#define VARANGE_52 52 + /* id_aa64dfr0 */ #define ID_AA64DFR0_PMSVER_SHIFT 32 #define ID_AA64DFR0_CTX_CMPS_SHIFT 28 diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c index ca0685f33900..66583ac3be19 100644 --- a/arch/arm64/kernel/cpuinfo.c +++ b/arch/arm64/kernel/cpuinfo.c @@ -177,7 +177,9 @@ static int c_show(struct seq_file *m, void *v) seq_printf(m, "CPU architecture: 8\n"); seq_printf(m, "CPU variant\t: 0x%x\n", MIDR_VARIANT(midr)); seq_printf(m, "CPU part\t: 0x%03x\n", MIDR_PARTNUM(midr)); - seq_printf(m, "CPU revision\t: %d\n\n", MIDR_REVISION(midr)); + seq_printf(m, "CPU revision\t: %d\n", MIDR_REVISION(midr)); + seq_printf(m, "address sizes\t: %d bits physical, %d bits virtual\n\n", + id_aa64mmfr0_pa_range_bits(), id_aa64mmfr2_va_range_bits()); } return 0; -- 2.7.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] arm64: Expose address bits (physical/virtual) via cpuinfo 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 0 siblings, 1 reply; 8+ messages in thread From: Suzuki K Poulose @ 2019-01-29 10:09 UTC (permalink / raw) To: bhsharma, linux-arm-kernel Cc: mark.rutland, Steve.Capper, catalin.marinas, ard.biesheuvel, will.deacon, bhupesh.linux, kexec 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 > - LVA via CONFIG_ARM64_FORCE_52BIT > > 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 ? 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 : https://patchwork.kernel.org/patch/8669301/ Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] arm64: Expose address bits (physical/virtual) via cpuinfo 2019-01-29 10:09 ` Suzuki K Poulose @ 2019-01-30 19:48 ` Bhupesh Sharma 2019-02-04 16:54 ` James Morse 0 siblings, 1 reply; 8+ messages in thread From: Bhupesh Sharma @ 2019-01-30 19:48 UTC (permalink / raw) To: Suzuki K Poulose, linux-arm-kernel Cc: mark.rutland, Steve.Capper, catalin.marinas, ard.biesheuvel, will.deacon, bhupesh.linux, kexec 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 >> - LVA via CONFIG_ARM64_FORCE_52BIT >> >> 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 user-space: 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 - <https://github.com/sanskriti-s/pg-table_tests>), 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) CONFIG_X86_5LEVEL=y This test suite is easily modifiable for verifying 52-bit ARMv8.2-LVA support. 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): CONFIG_ARM64_64K_PAGES=y CONFIG_ARM64_USER_VA_BITS_52=y CONFIG_ARM64_VA_BITS=48 CONFIG_ARM64_PA_BITS_52=y CONFIG_ARM64_PA_BITS=52 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 <..snip..> processor : 31 <..snip..> CPU architecture: 8 <..snip..> 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 : > > https://patchwork.kernel.org/patch/8669301/ 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 <http://lists.infradead.org/pipermail/kexec/2019-January/022387.html> 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 support: 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. Thanks, Bhupesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] arm64: Expose address bits (physical/virtual) via cpuinfo 2019-01-30 19:48 ` Bhupesh Sharma @ 2019-02-04 16:54 ` James Morse 0 siblings, 0 replies; 8+ messages in thread From: James Morse @ 2019-02-04 16:54 UTC (permalink / raw) To: Bhupesh Sharma Cc: mark.rutland, Steve.Capper, catalin.marinas, ard.biesheuvel, will.deacon, bhupesh.linux, Suzuki K Poulose, kexec, linux-arm-kernel Hi Bhupesh, On 30/01/2019 19:48, Bhupesh Sharma wrote: > On 01/29/2019 03:39 PM, Suzuki K Poulose wrote: >> 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 >>> - LVA via CONFIG_ARM64_FORCE_52BIT >>> >>> 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 user-space: > > 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. Why do they need to know? What decision can you make with this information that you can't make without it? > For e.g. lets consider the 'pg-table_tests' (See - > <https://github.com/sanskriti-s/pg-table_tests>), 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, ... but we don't have 5-level pages tables ... > for which it uses either 'Intel 'la57' > cpu flag' in: > > $ cat /proc/cpuinfo', or > > $ grep CONFIG_X86_5LEVEL /boot/config-$(uname -r) > CONFIG_X86_5LEVEL=y > > This test suite is easily modifiable for verifying 52-bit ARMv8.2-LVA support. This looks like a test to check all kernel page-table walkers have been updated for a fifth level. We don't need to worry about this. You should just need to remove the arch-specific test. If you provide the hint on platforms that support it, the mapping should succeed. On platforms that don't, it won't. Why does user space need to know in advance of making the hint? > 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): I agree inspecting the Kconfig is an inappropriate way for user-space 'to know' what the kernel supports. I can only see a 'supports 52bit va' flag as being useful to a program that doesn't actually want to use it, but for some bizarre reason wants to know. For coredumps the question isn't "was it supported", but "was it in use", which you can tell from the pagetables. > 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 > <http://lists.infradead.org/pipermail/kexec/2019-January/022387.html> for details). vmcoreinfo is for things like crash/gdb/makedumpfile to provide kernel-specific information that they couldn't possibly work without. Like the page size. 52bit support doesn't fit here as a 52bit-aware walker works regardless of whether 52bit was in use. > 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 support: > > 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 seems you're expecting to know whether 52bit-VA is supported without actually using it. What is this useful for? The point of the hint is you want to allocate memory, and can work with 52bit-VA if the platform supports it. If it doesn't, you still want to allocate the memory. We shouldn't need a hint that the 52bit-va hint is supported. > It might be that I am missing other standard ABI mechanisms. If so, please point > me to the same. We also have HWCAP: Documentation/arm64/elf_hwcaps.txt These are used for things the program may need to run: like floating point, or the presence of particular instructions. User-space absolutely has to know about these in advance, as it will get a SIGILL if support is not present. 52bit VA doesn't fit here: memory is memory. Needing to know implies user-space is unwilling to use memory if the bits above 48bits aren't set. Thanks, James _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] arm64: Expose PARange via ID_AA64MMFR0_EL1 and VARange via ID_AA64MMFR2_EL1 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-28 20:57 ` Bhupesh Sharma 2019-01-29 10:14 ` Suzuki K Poulose 1 sibling, 1 reply; 8+ messages in thread From: Bhupesh Sharma @ 2019-01-28 20:57 UTC (permalink / raw) To: linux-arm-kernel Cc: mark.rutland, steve.capper, catalin.marinas, bhsharma, ard.biesheuvel, will.deacon, bhupesh.linux, kexec, suzuki.poulose ARMv8.2 architecture hardware extensions can support upto 52-bit physical addresses (ARMv8.2-LPA) and 52-bit virtual addresses (ARMv8.2-LVA). User-space utilities like 'makedumpfile' can try and use the getauxval() function to retrieve the underlying PARange and VARange values supported. An example implementation can be via the 'Appendix I: Example' shown in 'Documentation/arm64/cpu-feature-registers.txt'. A reference 'makedumpfile' implementation which uses a similar approach is available in [0]. So, we expose these properties via 'FTR_NONSTRICT' and 'FTR_VISIBLE' settings for 'ID_AA64MMFR0_PARANGE_SHIFT' and 'ID_AA64MMFR2_LVA_SHIFT'. [0]. https://github.com/bhupesh-sharma/makedumpfile/blob/9d7da4aad3efe79b448f48cc3454fcae46a316d6/arch/arm64.c#L499 Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> --- arch/arm64/kernel/cpufeature.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index f6d84e2c92fe..5cfc08cbf147 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -194,7 +194,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = { * Differing PARange is fine as long as all peripherals and memory are mapped * within the minimum PARange of all CPUs */ - ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_PARANGE_SHIFT, 4, 0), + ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_PARANGE_SHIFT, 4, 0), ARM64_FTR_END, }; @@ -211,7 +211,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = { static const struct arm64_ftr_bits ftr_id_aa64mmfr2[] = { ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_FWB_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_AT_SHIFT, 4, 0), - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_LVA_SHIFT, 4, 0), + ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_LVA_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_IESB_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_LSM_SHIFT, 4, 0), ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR2_UAO_SHIFT, 4, 0), -- 2.7.4 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] arm64: Expose PARange via ID_AA64MMFR0_EL1 and VARange via ID_AA64MMFR2_EL1 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 0 siblings, 1 reply; 8+ messages in thread From: Suzuki K Poulose @ 2019-01-29 10:14 UTC (permalink / raw) To: bhsharma, linux-arm-kernel Cc: mark.rutland, Steve.Capper, catalin.marinas, ard.biesheuvel, will.deacon, bhupesh.linux, kexec Hi, On 28/01/2019 20:57, Bhupesh Sharma wrote: > ARMv8.2 architecture hardware extensions can support > upto 52-bit physical addresses (ARMv8.2-LPA) and 52-bit virtual > addresses (ARMv8.2-LVA). > > User-space utilities like 'makedumpfile' can try and use the getauxval() > function to retrieve the underlying PARange and VARange values > supported. Why do we need VARange here ? This value could be different from the kernel VA. As for decoding the PTE, you could safely do the flip of the upper byte by checking the page size of 64K. What is the usecase for exposing the PARange ? > > An example implementation can be via the 'Appendix I: Example' shown > in 'Documentation/arm64/cpu-feature-registers.txt'. A reference > 'makedumpfile' implementation which uses a similar approach is > available in [0]. > > So, we expose these properties via 'FTR_NONSTRICT' and 'FTR_VISIBLE' > settings for 'ID_AA64MMFR0_PARANGE_SHIFT' and 'ID_AA64MMFR2_LVA_SHIFT'. What is the rationale behind changing the feature to NONSTRICT ? > > [0]. https://github.com/bhupesh-sharma/makedumpfile/blob/9d7da4aad3efe79b448f48cc3454fcae46a316d6/arch/arm64.c#L499 Btw, if you are not using a 64K page size, the usage of the lva support feature could corrupt your PTE-> PHYS conversion, unless I am missing something. Suzuki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] arm64: Expose PARange via ID_AA64MMFR0_EL1 and VARange via ID_AA64MMFR2_EL1 2019-01-29 10:14 ` Suzuki K Poulose @ 2019-01-30 20:27 ` Bhupesh Sharma 0 siblings, 0 replies; 8+ messages in thread From: Bhupesh Sharma @ 2019-01-30 20:27 UTC (permalink / raw) To: Suzuki K Poulose, linux-arm-kernel Cc: mark.rutland, Steve.Capper, catalin.marinas, ard.biesheuvel, will.deacon, bhupesh.linux, kexec Hi Suzuki, Thanks for the review. On 01/29/2019 03:44 PM, Suzuki K Poulose wrote: > Hi, > > On 28/01/2019 20:57, Bhupesh Sharma wrote: >> ARMv8.2 architecture hardware extensions can support >> upto 52-bit physical addresses (ARMv8.2-LPA) and 52-bit virtual >> addresses (ARMv8.2-LVA). >> >> User-space utilities like 'makedumpfile' can try and use the getauxval() >> function to retrieve the underlying PARange and VARange values >> supported. > > Why do we need VARange here ? This value could be different from the > kernel VA. As for decoding the PTE, you could safely do the flip > of the upper byte by checking the page size of 64K. I shared the makedumpfile implementation (for decoding the PTE) just as an example, however there can be other user-space applications, for e.g a user-space application running with 48-bit kernel VA and 52-bit user space VA and requesting allocation in 'high' address via a 'hint' to mmap (See <http://lists.infradead.org/pipermail/kexec/2019-January/022389.html> for details). As I mentioned in the reply to the 1/2 PATCH review, I can see only two methods to determine the underlying kernel support in such cases: a). Read the CONFIG flags from .config, or b). In absence of .config file on the system, read the system ID registers like 'ID_AA64MMFR0_EL1' and 'ID_AA64MMFR2_EL1' and then make a decision on whether to pass a hint to 'mmap'. > What is the usecase for exposing the PARange ? Again it's perfectly possible to use a 48-bit VA in kernel/user-space and 52-bit PA overall. This means that the user-space applications need to again depend on reading CONFIG file changes for reading the PARange and VARange values to determine the actual values set on the hardware before they can make a 'mmap' call. Also one can use the VARange and PARange values (printed or returned as part of the user-space application code) to inform the overall calling benchmarkingtest-suite about the address space configuration for which the test-suite was executed. >> >> An example implementation can be via the 'Appendix I: Example' shown >> in 'Documentation/arm64/cpu-feature-registers.txt'. A reference >> 'makedumpfile' implementation which uses a similar approach is >> available in [0]. >> >> So, we expose these properties via 'FTR_NONSTRICT' and 'FTR_VISIBLE' >> settings for 'ID_AA64MMFR0_PARANGE_SHIFT' and 'ID_AA64MMFR2_LVA_SHIFT'. > > What is the rationale behind changing the feature to NONSTRICT ? Yes, this seems like a left-over. Will fix in v2. >> >> [0]. >> https://github.com/bhupesh-sharma/makedumpfile/blob/9d7da4aad3efe79b448f48cc3454fcae46a316d6/arch/arm64.c#L499 >> > > Btw, if you are not using a 64K page size, the usage of the lva support > feature could corrupt your PTE-> PHYS conversion, unless I am missing > something. Fedora arm64 servers use 64K page size by default. Also as a side note, perhaps the ABI example for the system id register access <https://www.kernel.org/doc/Documentation/arm64/cpu-feature-registers.txt> needs to be updated for ARMv8.2 (as it doesn't support ID_AA64MMFR2_EL1 via get_cpu_ftr(). May be I can send a separate patch to address the same. Please let me know your thoughts on the same. Thanks, Bhupesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-02-04 17:06 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).