Hi Bhupesh,

On 04/02/2019 14:35, Bhupesh Sharma wrote:

On 01/31/2019 03:09 AM, Bhupesh Sharma wrote:

quoted

On 01/30/2019 08:51 PM, James Morse wrote:

quoted

On 01/30/2019 12:23 PM, 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].

Why does it need to know?

(Suzuki asked the same question on your earlier version)
https://lore.kernel.org/linux-arm-kernel/cff44754-7fe4-efea-bc8e-4dde2277c821@arm.com/ (local)

quoted

I have shared some details (after discussion with our test teams) in reply to
the review comments from Suzuki here:
http://lists.infradead.org/pipermail/kexec/2019-January/022389.html, and
http://lists.infradead.org/pipermail/kexec/2019-January/022390.html

Just to summarize, I mentioned in my replies to the review comments tha the
makedumpfile implementation (for decoding the PTE) was 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.

But vmcoreinfo is the wrong place to expose this information. (it can be
configured off, and is only accessible to root)

quoted

quoted

 From your github link it looks like you use this to re-assemble the two bits
of the PFN from the pte. Can't you always do this for 64K pages? CPUs with
the feature always do this too, its not something the kernel turns on.

Ok, let me try to give some perspective of a common makedumpfile use-case
before I jump into the details:

quoted

Also hardcoding the PTE calculation to use the high address bit mask always
will break the backward compatibility with older kernels (which don't support
52-bit address space extensions).

What would go wrong?

The hardware ignores those bits and supplies zero. As far as I can see the
kernel has always generated zero there.

quoted

(b). Also x86_64 already has a vmcoreinfo export for 'pgtable_l5_enabled':

So? 5-level page tables is a different feature. I agree you need to know the
number of levels to walk the page-tables, but that isn't how arm64's 52bit stuff
works.

Ping. Since this patch fixes a regression with user-space tools like
makedumpfile and crash-utility which are broken since arm64 kernels with 52-bit
VA and PA support are available (and distributions which enable them), would
request review comments/ack on this simple change.

Broken how? What goes wrong?

I can see how a not-52bit-aware crash/gdb/whatever would be confused by high
bits being set in the physical address, and possibly throw them away.
But once it supports this for 64K pages, I don't see what can go wrong if those
bits aren't set. Why does it need to know?


Thanks,

James

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