Bug#834505: arm64 boot failure with large physical memory range
X-Debbugs-CC: ard.biesheuvel@linaro.org
On Sun, Aug 21, 2016 at 03:04:02PM +0100, Ian Campbell wrote:
> On Sun, 2016-08-21 at 11:42 +0100, Leif Lindholm wrote:
> >
> > 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.
>
> Wouldn't the equivalent scenario on x86 result in taking faults (#GP
> IIRC) due to them being non-canonical addresses? (Which are basically
> Intel's way of forbidding the use of bits above the physical address
> size when registers are used in pointer-like ways, i.e. for
> loads/stores or jump targets etc).
Right so most of my confusion here was related to my belief that the
address masking was in fact not correct in the first place. Speaking
to Ard, that appears to not be the case here.
> I thought there was a control bit on ARMv8 too which made it cause a
> fault if the code loaded through, stored via, branched to etc an
> address with bits set between the maximum physical address bit and the
> bits architecturally reserved for tagging at the top end of the word,
> but perhaps my memory has simply fabricated that out of thing air?
I don't remember if there's a dedicated bit for that, but certainly
judicious use of TTBCR/TTBRn should be able to achieve the same.
/
Leif
Reply to: