On 30 September 2015 at 03:16, Andy Lutomirski [off-list ref] wrote:

On Tue, Sep 29, 2015 at 6:03 PM, H. Peter Anvin [off-list ref] wrote:

quoted

On 09/27/2015 12:06 AM, Ingo Molnar wrote:

quoted

* Ard Biesheuvel [off-list ref] wrote:

quoted

quoted

If we allocate the EFI runtime as a single virtual memory block then issues
like rounding between sections does not even come up as a problem: we map the
original offsets and sizes byte by byte.

Well, by that reasoning, we should not call SetVirtualAddressMap() in the first
place, and just use the 1:1 mapping UEFI uses natively. This is more than
feasible on arm64, and I actually fought hard against using
SetVirtualAddressMap() at all, but I was overruled by others. I think this is
also trivially possible on X64, since the 1:1 mapping is already active
alongside the VA mapping.

Could we please re-list all the arguments pro and contra of 1:1 physical mappings,
in a post that also explains the background so that more people can chime in, not
just people versed in EFI internals? It's very much possible that a bad decision
was made.

Pro: by far the sanest way to map the UEFI tables.
Con: doesn't actually work (breaks on several known platforms.)

Can we at least do 1:1 without an offset on arm64?  Given that Linux
seems to be more of a reference on arm64 than Windows is, maybe that
would give everyone something vaguely sane to work with.

Yes, as I mentioned before in this thread, on arm64 this is very much
feasible, and it was my strong preference all along. However, the
arguments made by others that outweighed my preference were
(a) x86 uses it
(b) if we don't use it now, we will never be able to start using it
later since it will undoubtedly be broken in /some/ implementation in
the field.

As I also mentioned, the only minor complication is that arm64's VA
space may be configured to be smaller than the physical base of DRAM,
but I already had to address that for the boot ID map and KVM as well.

I will cook up a patch later today.

-- 
Ard.