Hi Bhupesh, On 04/02/2019 14:35, Bhupesh Sharma wrote: > On 01/31/2019 03:09 AM, Bhupesh Sharma wrote: >> On 01/30/2019 08:51 PM, James Morse wrote: >>> On 01/30/2019 12:23 PM, 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 >>>> >>>> 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@xxxxxxx/ >> 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) >>> 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: >> 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. >> (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 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
