[PATCH] ARM64: kernel: implement ACPI parking protocol

[Leif Lindholm]

On Fri, Aug 28, 2015 at 11:56:36AM -0400, Mark Salter wrote:
> > > > So that I understand: are you referring to memrange_efi_to_native()
> > > > in arch/arm64/kernel/efi.c ? Is it safe to round up (and add it to
> > > > the memblock layer) the memory region size to PAGE_SIZE without 
> > > > checking
> > > > attributes of overlapping (within PAGE_SIZE) UEFI regions ?
> > > 
> > > The problem is that nothing in the UEFI spec or parking protocol spec
> > > prevents firmware from placing a 4K parking protocol mailbox area in
> > > the same 64K page as normal cached memory which winds up mapped in
> > > the kernel linear mapping. The kernel might be able to work around
> > > that by not putting the 64K page in the linear map. There's nothing
> > > the kernel could do if the mailbox is in same 64K page with UEFI 
> > > runtime memory which would use a cached mapping.

Indeed.

> > Ok, I failed to explain myself. Let's imagine that we have a, say, 64k
> > aligned memory region (EFI_MEMORY_WB - size 16k) that lives in the same
> > 64K memory frame as a device's registers memory space.
> > The code I pointed at above creates a 64K memory frame out of the 16K
> > region and adds it to the memblock so that it ends up in the kernel 
> > linear
> > mapping which ends up mapping the device registers too with cacheable
> > attributes and that's not correct.
> > 
> > I am not sure what's the best way to solve that, probably we should
> > amend the UEFI specs to enforce uniform 64K memory region attributes,
> > comments welcome.

Agreed.

> OIC. Well it is a potential problem. Hardware designers do some whacky
> things, but I'd like to think I/O regions and cached mem regions bordering
> on such a small power of two boundary is not one of them.

Sure. But the same applies to memory regions _mapped_ as Device.
Which is (apparently) necessary for the spin-tables used by the
parking protocol.

So the spec should ban use of incompatible memory attributes between
any regions kept around at runtime, as opposed to specifically the
regions used for runtime services (the current wording in the spec).

/
    Leif