In an ideal world, we'd get systbl and efi memory map from
/sys/firmware/efi somewhere. They are currently not published,
but may be in the future.

The systab comes from the first call to the EFI entry point and there's
no way to find it otherwise.

Memmap is obtained from BootServices which is long gone. And besides,
it's modified for the runtime entries for the call to
SetVirtualAddresses call in runtime services. Even though that's in
runtime services, it can be called only once.

kexec tools + Pandora don't need this because pandora copyies this
structure over when the new kernel is a bzImage. Our current trampoline
doesn't do that, so we have to get it from the current kernel. Even so,
we have to pass the PAs for the memory map to the trampoline which
copies this over (in part so we can boot an modified kernel, otherwise
we could put this into an alternative entry point, but those are hard to
manage).

So, we can sig out the PA of the memory map via this method, but some
care is needed. For the initial round, it suffices. However, Linux on
x86 does some odd things with EFI_RUNTIME that need to be preserved (so
this is a temporary measure until we get the /sys/firmware/efi code
working). The Linux kernel keeps this memory around, but it's not clear
how long. It stops referencing it after it converts it to the BIOS e820
memory map array it uses elsewhere. It seems to be OK to use since our
use case is an immediate boot to FreeBSD, not a boot after Linux runs a
while and had a chance to (maybe) overwrite this data.

Migrating to a proper interface that publishes the modified EFI
map in /sys/firmware/efi/memmap is in the future.

Update the trampoline to copy this data before jumping into the kernel.
We use the simple laucnhing interface instead of the bzImage interface
that kexec_file() uses, so there's no last-second chance to use the
boot params data.

Sponsored by: Netflix