Bug#834505: arm64 boot failure with large physical memory range
On Sun, Aug 21, 2016 at 01:11:15AM +0100, Ben Hutchings wrote:
> > > > I think this would be opening up a real can of worms. Not all sizes
> > > > are supported by the architecture, and only certain VA_BITS/pagesize
> > > > combinations work in the kernel.
> > > >
> > > > We could switch to 42-bit VA, but that would require switching to 64K
> > > > pagesize, which would be an even huger can.
> > >
> > > I'm not suggesting using any unusual page table configuration. Just
> > > reducing the ASLR range that is currently implied by a 48-bit VA.
> >
> > But would that help anything?
> > Even if you don't allocate to the top bits, if they're used for
> > tagging, you'll still segfault.
>
> I seem to remember that AArch64 has the ill-advised rule that VA bits
> outside the range of the current page table format are ignored, so
> presumably you're concerned that the code relies on this. But since
> other 64-bit architectures (at least x86, PowerPC and SPARC) behave
> otherwise, I would expect semi-portable code to mask out the tag bits.
You're not wrong, but unfortunately the ability to write semi-portable
code left the planet over a decade ago. For clarification - the
problem is not with regards to code written specifically for arm64 and
not verified with different MMU-configurations, but with code written
for x86 and never tested on anything else. See my post to cross-distro
last week (and the subsequent thread):
https://lists.linaro.org/pipermail/cross-distro/2016-August/000838.html
So simply adjusting the mmap range on Debian would result in us using
less verified code paths without it helping with the problem at hand.
/
Leif
Reply to: