Commit Graph

14 Commits

Author SHA1 Message Date
Victor Sun c74b1941a0 HV: split sanitize_multiboot_info api
Previously sanitize_multiboot_info() was called after init_debug_pre() because
the debug message can only print after uart is initialized. On the other hand,
multiboot cmdline need to be parsed before init_debug_pre() because the cmdline
could override uart settings and make sure debug message printed successfully.
This cause multiboot info was parsed in two stages.

The patch revise the multiboot parse logic that split sanitize_multiboot_info()
api and use init_acrn_multiboot_info() api for the early stage. The most of
multiboot info will be initialized during this stage and no debug message need
to be printed. After uart is initialized, the sanitize_multiboot_info() would
do sanitize multiboot info and print needed debug messages.

Tracked-On: #4885

Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-06-08 13:30:04 +08:00
Victor Sun 52f26cba8a hv: a few fixes for multiboot2 boot
- need to specify the load_addr in the multiboot2 address tag. GRUB needs
  it to correctly calculate the ACRN binary's load size if load_end_addr is
  a non-zero value.

- multiboot2 can be enabled if hypervisor relocation is disabled.

- print the name of the boot loader. This might be helpful if the boot
  loader, e.g. GRUB, inludes its version in the name string.

Tracked-On: #4441
Signed-off-by: Victor Sun <victor.sun@intel.com>
Signed-off-by: Zide Chen <zide.chen@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
2020-03-24 08:44:20 +08:00
Victor Sun 19ffaa50dc HV: init and sanitize acrn multiboot info
Initialize and sanitize a acrn specific multiboot info struct with current
supported multiboot1 in very early boot stage, which would bring below
benifits:

- don't need to do hpa2hva convention every time when refering boot_regs;

- panic early if failed to sanitize multiboot info, so that don't need to
  check multiboot info pointer/flags and panic in later boot process;

- keep most code unchanged when introduce multiboot2 support in future;

Tracked-On: #4419

Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-02-26 09:24:16 +08:00
Victor Sun 520a0222d3 HV: re-arch boot component header
The patch re-arch boot component header files by:

- moving multiboot.h from include/arch/x86/ to boot/include/ and keep
  this header for multiboot1 protocol data struct only;

- moving multiboot related MACROs in cpu_primary.S to multiboot.h;

- creating an independent boot.h to store acrn specific boot information
  for other files' reference;

Tracked-On: #4419

Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2020-02-26 09:24:16 +08:00
Alexander Merritt 8ddbfc268c acrn: add pxelinux as known bootloader
Tracked-On: #4389
Signed-off-by: Alexander Merritt <alex.merritt@intel.com>
2020-02-17 08:49:02 +08:00
Victor Sun 15da33d8af HV: parse default pci mmcfg base
The default PCI mmcfg base is stored in ACPI MCFG table, when
CONFIG_ACPI_PARSE_ENABLED is set, acpi_fixup() function will
parse and fix up the platform mmcfg base in ACRN boot stage;
when it is not set, platform mmcfg base will be initialized to
DEFAULT_PCI_MMCFG_BASE which generated by acrn-config tool;

Please note we will not support platform which has multiple PCI
segment groups.

Tracked-On: #4157

Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-12-02 16:20:24 +08:00
Zhao Yakui cee2f8b288 ACRN/HV: Refine the function of init_vboot to initialize the depriv_boot env correctly
Currently when get_rsdp is called, the EFI depriv_boot env is not initialized.
In such case it will fallback to the legacy mechanism of ACPI table.
If the ACPI table based on legacy mechanism is not found, it will fail to get
the ACPI table and then the system will hang.
On the old platform it still can parse the ACPI table from legacy mechanism.
In fact when EFI RSDP exists, the EFI RSDP is preferred instead of legacy ACPI
RSDP.

In order to avoid multiple calling of depriv_init_boot, the init_boot_operations
is renamed and called after X2apic is enabled(early_init_lapic).

Tracked-On: #3184
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
2019-05-30 14:07:57 +08:00
Jason Chen CJ 238d8bbaa2 reshuffle init_vm_boot_info
now only SOS need decide boot with de-privilege or direct boot mode, while
for other pre-launched VMs, they should use direct boot mode.

this patch merge boot/guest/direct_boot_info.c &
boot/guest/deprivilege_boot_info.c into boot/guest/vboot_info.c,
and change init_direct_vboot_info() function name to init_general_vm_boot_info().

in init_vm_boot_info(), depend on get_sos_boot_mode(), SOS may choose to init
vm boot info by setting the vm_sw_loader to deprivilege specific one; for SOS
using DIRECT_BOOT_MODE and all other VMS, they will use general_sw_loader as
vm_sw_loader and go through init_general_vm_boot_info() for virtual boot vm
info filling.

this patch also move spurious handler initilization for de-privilege mode from
boot/guest/deprivilege_boot.c to boot/guest/vboot_info.c, and just set it in
deprivilege sw_loader before irq enabling.

Changes to be committed:
	modified:   Makefile
	modified:   arch/x86/guest/vm.c
	modified:   boot/guest/deprivilege_boot.c
	deleted:    boot/guest/deprivilege_boot_info.c
	modified:   boot/guest/direct_boot.c
	renamed:    boot/guest/direct_boot_info.c -> boot/guest/vboot_info.c
	modified:   boot/guest/vboot_wrapper.c
	modified:   boot/include/guest/deprivilege_boot.h
	modified:   boot/include/guest/direct_boot.h
	modified:   boot/include/guest/vboot.h
	new file:   boot/include/guest/vboot_info.h
	modified:   common/vm_load.c
	modified:   include/arch/x86/guest/vm.h

Tracked-On: #1842
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
2019-05-20 18:49:59 +08:00
Victor Sun 1aac0dffaf HV: hot fix on usage of CONFIG_ACPI_PARSE_ENABLED
The acpi_fixup() is only called when CONFIG_ACPI_PARSE_ENABLED is enabled;

Tracked-On: #3107

Signed-off-by: Victor Sun <victor.sun@intel.com>
2019-05-15 09:31:21 +08:00
Victor Sun 8afbdb7505 HV: enable Kconfig of ACPI_PARSE_ENABLED
Previously we use Kconfig of DMAR_PARSE_ENABLED to choose pre-defined DMAR info
or parse it at runtime, at the same time we use MACRO of CONFIG_CONSTANT_ACPI
to decide whether parse PM related ACPI info at runtime. This looks redundant
so use a unified ACPI_PARSE_ENABLED Kconfig to replace them.

Tracked-On: #3107

Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-05-14 11:53:02 +08:00
Jason Chen CJ 7494ed2775 Clean up MISRA C violation
clean up a few MISRA C violations that can be fixed by code change in vboot files

Tracked-On: #861
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
2019-05-09 16:33:44 +08:00
Jason Chen CJ d364d352f8 reshuffle struct vboot_candidates
struct vboot_candidates is private, so move it into source file, and change it
to a more suitable name vboot_bootloader_map.
this patch also add sos_boot_mode to indicate if the sos boot is using de-privilege
or direct boot mode.

Tracked-On: #1842
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
2019-05-09 16:33:44 +08:00
Jason Chen CJ 41ac9e5d10 rename function & definition from firmware to guest boot
The interface struct & API changes like below:
  struct uefi_context->struct depri_boot_context
  init_firmware_operations()->init_vboot_operations()
  init_firmware()->init_vboot()
  firmware_init_irq()->init_vboot_irq()
  firmware_get_rsdp()->get_rsdp_ptr()
  firmware_get_ap_trampoline()->get_ap_trampoline_buf()
  firmware_init_vm_boot_info()->init_vm_boot_info()

Tracked-On: #1842
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-05-09 16:33:44 +08:00
Jason Chen CJ 20f97f7559 restruct boot and bsp dir for firmware stuff
currently, ACRN hypervisor can either boot from sbl/abl or uefi, that's
why we have different firmware method under bsp & boot dirs.
but the fact is that we actually have two different operations based on
different guest boot mode:
1. de-privilege-boot: ACRN hypervisor will boot VM0 in the same context as
native(before entering hypervisor) - it means hypervisor will co-work with
ACRN UEFI bootloader, restore the context env and de-privilege this env
to VM0 guest.
2. direct-boot: ACRN hypervisor will directly boot different pre-launched
VM(including SOS), it will setup guest env by pre-defined configuration,
and prepare guest kernel image, ramdisk which fetch from multiboot modules.

this patch is trying to:
- rename files related with firmware, change them to guest vboot related
- restruct all guest boot stuff in boot & bsp dirs into a new boot/guest dir
- use de-privilege & direct boot to distinguish two different boot operations

this patch is pure file movement, the rename of functions based on old assumption will
be in the following patch.

Changes to be committed:
	modified:   ../efi-stub/Makefile
	modified:   ../efi-stub/boot.c
	modified:   Makefile
	modified:   arch/x86/cpu.c
	modified:   arch/x86/guest/vm.c
	modified:   arch/x86/init.c
	modified:   arch/x86/irq.c
	modified:   arch/x86/trampoline.c
	modified:   boot/acpi.c
	renamed:    bsp/cmdline.c -> boot/cmdline.c
	renamed:    bsp/firmware_uefi.c -> boot/guest/deprivilege_boot.c
	renamed:    boot/uefi/uefi_boot.c -> boot/guest/deprivilege_boot_info.c
	renamed:    bsp/firmware_sbl.c -> boot/guest/direct_boot.c
	renamed:    boot/sbl/multiboot.c -> boot/guest/direct_boot_info.c
	renamed:    bsp/firmware_wrapper.c -> boot/guest/vboot_wrapper.c
	modified:   boot/include/acpi.h
	renamed:    bsp/include/firmware_uefi.h -> boot/include/guest/deprivilege_boot.h
	renamed:    bsp/include/firmware_sbl.h -> boot/include/guest/direct_boot.h
	renamed:    bsp/include/firmware.h -> boot/include/guest/vboot.h
	modified:   include/arch/x86/multiboot.h

Tracked-On: #1842
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-05-09 16:33:44 +08:00