efi: export efi runtime memory mapping to sysfs

kexec kernel will need exactly same mapping for
efi runtime memory ranges. Thus here export the
runtime ranges mapping to sysfs, kexec-tools
will assemble them and pass to 2nd kernel via
setup_data.

Introducing a new directory /sys/firmware/efi/runtime-map
Just like /sys/firmware/memmap. Containing below attribute
in each file of that directory:
attribute  num_pages  phys_addr  type  virt_addr

Changelog:
 - Cleaup code, add function efi_save_runtime_map
 - Improve err handling
 - Add macros for sysfs _show functions
 - Remove forward declarations.
 Matt:
 - s/efi-runtime-map.c/runtime-map.c
 - Change dir name to runtime-map
 - Changelog and documentation fixes.
 - Documentation fixes.
 - Update to use desc_size in efi_runtime_map
 - Kconfig EFI_RUNTIME_MAP depends on X86 && KEXEC && EFI
 Boris:
 - Documentation grammar/spelling fix
 - krealloc fix.
 - Move efi_runtime_map_init to efisubsys_initcall.
 - Remove 'if EXPERT' for EFI_RUNTIME_MAP Kconfig option
 - save_runtime_map: move error handling code into the function itself.
 - other code improvement.

Signed-off-by: Dave Young <dyoung@redhat.com>
efi: passing kexec necessary efi data via setup_data

Add a new setup_data type SETUP_EFI for kexec use.
Passing the saved fw_vendor, runtime, config tables and efi runtime mappings.

When entering virtual mode, directly mapping the efi runtime ragions which
we passed in previously. And skip the step to call SetVirtualAddressMap.

Specially for HP z420 workstation we need save the smbios physical address.
The kernel boot sequence proceeds in the following order.  Step 2
requires efi.smbios to be the physical address.  However, I found that on
HP z420 EFI system table has a virtual address of SMBIOS in step 1.  Hence,
we need set it back to the physical address with the smbios in
efi_setup_data.  (When it is still the physical address, it simply sets
the same value.)

1. efi_init() - Set efi.smbios from EFI system table
2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
3. efi_enter_virtual_mode() - Map EFI ranges

Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
HP z420 workstation.

v2: refresh based on previous patch changes, code cleanup.
v3: use ioremap instead of phys_to_virt for efi_setup
v5: improve some code structure per comments from Matt
    Boris: improve code structure, spell fix, etc.
    Improve changelog from Toshi.
    change the variable efi_setup to the physical address of efi setup_data
    instead of the ioremapped virt address
v6: Boris: Documentation fixes
           move parse_efi_setup to efi_$(BITS).c
           simplify parse_efi_setup logic
    Matt: check return value of efi_reuse_config

Signed-off-by: Dave Young <dyoung@redhat.com>
efi: only print saved efi runtime maps instead of all memmap ranges for kexec

For kexec/kdump kernel efi runtime mappings are saved, printing original whole
memmap ranges does not make sense anymore. So introduce a new function to only
print runtime maps in case kexec/kdump kernel is used.

changelog:
Matt: use efi_setup instead of esdata
      share function print_efi_memmap for both normal and kexec boot.

Signed-off-by: Dave Young <dyoung@redhat.com>
x86: add xloadflags bit for efi runtime support on kexec

Old kexec-tools can not load new kernel. The reason is kexec-tools do not fill
efi_info in x86 setup header previously, thus efi failed to initialize.
In new kexec-tools it will by default fill efi_info and pass other efi required
infomation to 2nd kernel so kexec kernel efi initialization can succeed finally.

To prevent from breaking userspace, add a new xloadflags bit so kexec-tools
can check the flag and switch to old logic.

changelog:
Matt: +&& defined(CONFIG_KEXEC)
      improve patch description.
HPA: document the flag.

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
x86: export x86 boot_params to sysfs

kexec-tools use boot_params for getting the 1st kernel hardware_subarch,
the kexec kernel efi runtime support also need read the old efi_info from
boot_params. Currently it exists in debugfs which is not a good place for
such infomation. Per HPA, we should avoid of "sploit debugfs".

In this patch /sys/kernel/boot_params are exported, also the setup_data is
exported as a subdirectory. kexec-tools is using debugfs for hardware_subarch
for a long time now so we're not removing it yet.

Structure is like below:

/sys/kernel/boot_params
|__ data                /* boot_params in binary*/
|__ setup_data
|   |__ 0               /* the first setup_data node */
|   |   |__ data        /* setup_data node 0 in binary*/
|   |   |__ type        /* setup_data type of setup_data node 0, hex string */
[snip]
|__ version             /* boot protocal version (in hex, "0x" prefixed)*/

Changelog:
Greg: use __ATTR_RO() and group attr.
Matt and Boris: Documentation improvement, code indentation.
Documentation fix.

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
x86: reserve setup_data ranges late after parsing memmap cmdline

Currently e820_reserve_setup_data is called before parsing early params,
it works in normal case. But for memmap=exactmap, the final memory ranges
are created after parsing memmap= cmdline params, so the previous
e820_reserve_setup_data has no effect. For example, setup_data ranges
will still be marked as normal system ram, thus when later sysfs driver
ioremap them kernel will warn about mapping normal ram.

This patch fix it by moving the e820_reserve_setup_data callback after
parsing early params so they can be set as reserved ranges and later
ioremap will be fine with it.

changes:
Boris: improve patch description

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Borislav Petkov <bp@suse.de>
x86: kdebugfs do not use __va for getting setup_data virt addr

kdump kernel will use memmap=exactmap kernel cmdline, but __va does not
work in case memmap=exactmap, so let's always use ioremap_cache.

Signed-off-by: Dave Young <dyoung@redhat.com>