[PATCH v2 09/10] arm64/efi: ignore unusable regions instead of reserving them

[Mark Salter]

On Mon, 2014-11-10 at 08:31 +0100, Ard Biesheuvel wrote:
> On 10 November 2014 05:11, Mark Salter <msalter at redhat.com> wrote:
> > On Thu, 2014-11-06 at 15:13 +0100, Ard Biesheuvel wrote:
> >> This changes the way memblocks are installed based on the contents
> of
> >> the UEFI memory map. Formerly, all regions would be
> memblock_add()'ed,
> >> after which unusable regions would be memblock_reserve()'d as well.
> >> To simplify things, but also to allow access to the unusable
> regions
> >> through mmap(/dev/mem), even with CONFIG_STRICT_DEVMEM set, change
> >> this so that only usable regions are memblock_add()'ed in the first
> >> place.
> >
> > This patch is crashing 64K pagesize kernels during boot. I'm not
> exactly
> > sure why, though. Here is what I get on an APM Mustang box:
> >
> 
> Ah, yes, I meant to mention this patch
> 
> https://git.kernel.org/cgit/linux/kernel/git/glikely/linux.git/commit/?id=8cccffc52694938fc88f3d90bc7fed8460e27191
> 
> in the cover letter, which addresses this issue at least for the DT
> case.
> 

That isn't the problem. In general, with 64K kernel pages, you can't be
sure if you leave something you need out of the kernel linear mapping.
If you have Loader Code/Data regions begin and/or end at something other
than a 64K boundary and that region is adjacent to a region not being
added, then you end up leaving out the unaligned bits from the linear
mapping. This could be bits of the initramfs or devicetree.

What I don't get with this failure is that it is an alignment fault
which should be masked at EL1 for the kernel. The same unaligned
access happens without this patch and it doesn't generate a fault.