Hi Robin,

On 02/04/2019 09:01 PM, Robin Murphy wrote:

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

quoted

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).

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.

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