Commit Graph

9 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
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
708cae7c88 HV: remove DBG_LEVEL_PARSE
- It is meaningless to enable debug function in parse_hv_cmdline() because
the function run in very eary stage and uart has not been initialized at
that time, so remove this debug level definition;

- Rewrite parse_hv_cmdline() function to make it compliant with MISRA-C;

- Decouple uart16550 stuff from Init.c module and let console.c handle it;

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
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
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