Hi Kazu,

On 02/04/2019 09:34 PM, Kazuhito Hagio wrote:

On 1/30/2019 8:48 PM, Dave Young wrote:

quoted

+ more people
On 01/30/19 at 05:53pm, Bhupesh Sharma wrote:

quoted

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.

User-space tools like 'makedumpfile' and 'crash-utility' can instead
use the 'MAX_USER_VA_BITS' and 'MAX_PHYSMEM_BITS' values to determine
the maximum virtual address and physical address (respectively)
supported by underlying kernel.

A reference 'makedumpfile' implementation which uses this approach to
determining the maximum physical address is available in [0].

[0].

https://github.com/bhupesh-sharma/makedumpfile/blob/52-bit-pa-support-via-vmcore-v1/arch/arm64.c#L490

I'm not objecting the patch, just want to make sure to make clear about
things and make sure these issues are aware by people, and leave arm
people to review the arm bits.

1. MAX_PHYSMEM_BITS
As we previously found, back to 2014 makedumpfile took a patch to read the
value from vmcore but the kernel patch was not accepted.
So we should first make clear if this is really needed, why other arches
do not need this in makedumpfile.

If we really need it then should it be arm64 only?

If it is arm64 only then the makedumpfile code should read this number
only for arm64.

Sorry for the delay.

According to the kernel patch, some of arm32 platforms may need it
http://lists.infradead.org/pipermail/kexec/2014-May/011909.html
but except for them (and arm64), makedumpfile can manage with kernel
version and some switches to determine this value so far.

quoted

Also Lianbo added the vmcoreinfo documents, I believe it stays in -tip
tree,  need to make sure to document this as well.

2. MAX_USER_VA_BITS
Does makedumpfile care about userspace VA bits?  I do not see other code
doing this,  Kazu and Dave A should be able to comment.

The mapping makedumpfile uses on arm64 is swapper_pg_dir only, so
unless the config affects its structure or something, makedumpfile
will not need this value.

I captured this case in more details while sending out the makedumpfile  
enablement patch for ARMv8.2-LVA (see [0]), but here is a brief summary  
on the same:

Since at the moment we enable the support of the ARMv8.2-LVA extension  
for 52-bit user-space VA in the kernel via a CONFIG flags  
(CONFIG_ARM64_USER_VA_BITS_52), so there are no clear mechanisms in  
user-space to determine this CONFIG
flag value and use it to determine the address range values.

Since 'VA_BITS' are already exported via vmcoreinfo, if we export  
'MAX_USER_VA_BITS' as well, we can use the same in user-space to check  
if the 'MAX_USER_VA_BITS' value is greater than 'VA_BITS'. If yes, then  
we are running a use-case where user-space is 52-bit while the  
underlying kernel is still 48-bit.

The increased 'PTRS_PER_PGD' value for such cases needs to be then  
calculated as is done by the underlying kernel (see  
'arch/arm64/include/asm/pgtable-hwdef.h' for details):

#define PTRS_PER_PGD		(1 << (MAX_USER_VA_BITS - PGDIR_SHIFT))

Also, note that 'arch/arm64/include/asm/memory.h' defines  
'MAX_USER_VA_BITS' as 'VA_BITS' in case 'CONFIG_ARM64_USER_VA_BITS_52'  
is set to 'n':

#ifdef CONFIG_ARM64_USER_VA_BITS_52
#define MAX_USER_VA_BITS	52
#else
#define MAX_USER_VA_BITS	VA_BITS
#endif

So, makedumpfile will need this symbol exported in vmcore to make the  
above determination.

[0]. http://lists.infradead.org/pipermail/kexec/2019-February/022425.html

Thanks,
Bhupesh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel