Hi Robin,
On 02/04/2019 09:01 PM, Robin Murphy wrote:
On 04/02/2019 14:35, Bhupesh Sharma wrote:
[...]
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).
No it won't. There's no difference between an old kernel, a new kernel
on a CPU without ARMv8.2-LPA, or a new kernel on a CPU with ARMv8.2-LPA
in a system which happens to have less than 49 bits of physical memory
map - in all those cases the relevant bits are either RES0 or just
actually 0 in the PTE, so replacing 4 bits of zeros with 4 bits of other
zeros in the final physical address has no effect whatsoever other than
taking a couple of extra instructions to perform.
Right, but lets think this from a distribution user p-o-v. Why would a
user with newer kernel and CPU which doesn't support ARMv8.2 LPA want to
update a user-space utility? Well unless something is broken in the
user-space. Requesting an upgrade is easier in this case, as the
user-space components like crash-utility/kexec-tools (or for that matter
any user-space tool which requires a page-table walk to determine
vaddr/paddr values) are indeed broken with this combination.
On the other hand, if a user a having a old kernel, CPU which doesn't
support LPA, but if we still want them to upgrade to a newer version of
user-space utility (with a upgrade fix note reading something like: "Add
52-bit PA support"), surely that would not be an ideal case requiring an
upgrade as his underlying environment doesn't support the same.
That's what I meant when I said that we need to take care of the
backward compatibility also when we propose new code changes to
user-space packages.
Thanks,
Bhupesh
If you're running a 64K page kernel on a system with an SMMU, note how
that's already been "broken" for nearly a year now ;)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/io-pgtable-arm.c#n211
Robin.
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
