Commit Graph

17 Commits

Author SHA1 Message Date
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 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
Xiangyang Wu a13c19b450 HV:EFI-STUB:UEFI loader name supporting
In the current design, UEFI loader name is not supported,
it is hard to ditinguish UEFI boot loader (efi stub in
the code) from other multiboot compiliant boot loader (such
as SBL, ABL, GRUB etc) explicitly. From long term, it is
better that detect boot loader according to loader name and
use different boot method according to different boot loader
and VM configuration flag.

Allocate memory to store UEFI loader name statically, set
MULTIBOOT_INFO_BOOT_LOADER_NAME in flag of the multiboot header,
store host physical start address of loader name in the multiboot
header according to multiboot protocol.

V5-->V6:
	Update "Tracked-On"

Tracked-On: #2944

Signed-off-by: Xiangyang Wu <xiangyang.wu@linux.intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
2019-04-16 12:07:58 +08:00
Tw 334382f9ef efi-stub: minor change for uefi refactor
Include these changes:
- substitute efi_context with uefi_context
- remove EFI_STUB from Kconfig
- remove EFI_

Signed-off-by: Tw <wei.tan@intel.com>
2019-03-13 10:26:55 +08:00
Geoffroy Van Cutsem 2638518349 acrn.conf: clean-up SOS kernel options (EFI platforms)
- Remove some i915 options that are obsolete and irrelevant for the
Service OS kernel
- Update the various tutorials that also used these obsolete parameters

Tracked-On: #2518
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
2019-02-20 13:21:11 +08:00
wenlingz 3b7a010f7f Revert "Documentation: tweak GSG (and acrn.conf)"
This reverts commit c85172c342.
2019-02-15 20:48:00 +08:00
Geoffroy Van Cutsem c85172c342 Documentation: tweak GSG (and acrn.conf)
* Update kernel versions to the latest (to reflect the new 'release'
  number used in the 'iot-lts2018' kernel
* Add a one-line command to insert the PARTUUID into the acrn.conf
  file (without copying it all manually)

Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
2019-02-14 11:10:51 -08:00
Tw 18b04451e1 efi-stub: reset all APs after entering guest mode
In current hv implementation, we assume all AP have no context before
jumping into guest mode. But this is not true in all UEFI bios. BIOS
could have enabled all (or some of) APs at first. These APs could stay
in a run loop or wait for a semaphore. But after hv takes over control from
efi-stub, all of these AP environments will be simply dropped because
we don't support AP context save/restore for now. As a result,
BSP's ExitBootService will hang forver because it's waiting for AP in its
way (by waiting for a semaphore for example), unfortunately APs are now
in the context that hv provides in which they usually stay in idle loop.

To fix the issue above, we could have two solutions:
1. Save AP's runtime context before entering hv and restore context
after hv jumps back.
2. After hv jumps back, reset all the APs in the UEFI way, so the
previous context will be thrown away and a fresh new starts. Moreover
this new one is under virtualization.

Currently, we adopt the second one by disabling all the APs before
virtualization and then enabling them after hv jumps back. A reset
will be triggered. And this is guaranteed by UEFI MP Service protocol.

Tracked-On: #2435
Signed-off-by: Tw <wei.tan@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
2019-02-01 08:56:05 +08:00
Minggui Cao 723ff1f4ee HV: modularization improve UEFI macro control code
1. in UEFI bsp code, not need UEFI macro; it is controlled in makefile.
2. in vm/acpi/interrupt code, unify the API name for SBL & UEFI.
3. remove unnecessary header including and unused code.

Tracked-On: #1842
Signed-off-by: Minggui Cao <minggui.cao@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
2019-01-30 16:11:39 +08:00
Tw 69371f419b EFI: fix potential memory overwrite due to mmap table
Some bios may have more mmap table entry than our current limitation
which is 128. This will lead to a memory overwrite, so add a check to
prevent this and enlarge the limitation to 256. This should fix most
bioses.

Tracked-On: #2435
Signed-off-by: Tw <wei.tan@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
2019-01-29 11:01:34 +08:00
Chaohong guo a445a4eae0 EFI: Allocate EFI boot related struct from EFI allocation pool
Current EFI boot related structs are allocated right after HV binary, and
marked as EfiResered. In fact, the memory should be reclaimed and
managed by HV once EFI boot is done, Moreover, HV is doing 2M alignment,
which is overwriting this allocated memory. This patch is to allocate EFI
info from EFI allocation pool and marked as EFiloaderdata, so that the
memory is used by HV, also, it will reduce the fragmentation.

Tracked-On: #2349
Signed-off-by: Chaohong guo <chaohong.guo@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
Reviewed-by: Zheng, Gen <gen.zheng@intel.com>
2019-01-24 11:59:21 +08:00
Chaohong guo ad0f8bc3b1 EFI: Allocate 2M aligned memory for hypervisor image
Hypervisor does memory alignment during initializing paging(init_paging)
although the starting address allocated by EFI stub doesn't meet the
requirement. As a result, HV might overwrite some memory belong to UEFI
BIOS. The patch introduces a new routine to fix the issue.

Tracked-On: #2349
Signed-off-by: Chaohong guo <chaohong.guo@intel.com>
Reviewed-by: Zheng, Gen <gen.zheng@intel.com>
Reviewed-by: Zide Chen <zide.chen@intel.com>
2019-01-24 11:59:21 +08:00
wenlingz 34b4294334 Doc: Update GSG for v0.5 version and launch and acrn.conf sample script
modify sbl_up2 version and scripts
2019-01-16 16:28:26 +08:00
Alek Du 31487e829c Makefile: keep files used for debug target
1. keep symbols files for debug usage
2. they are saved when build for rootfs.

Tracked-On: #2168
Signed-off-by: Alek Du <alek.du@intel.com>
Signed-off-by: Minggui Cao <minggui.cao@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
2018-12-24 22:24:27 +08:00
Zhao Yakui e22b35e332 HV/DM: Unify the usage of aligned for structure definition with alignment
Now one macro is added to define the alignment requirement.
>#define __aligned(x) __attribute__((aligned(x)))

Some code uses the __aligned(x) to define the alignment while the other
code uses the original alignment definition.
So they are unified.

Tracked-On: projectacrn/acrn-hypervisor#2131
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
2018-12-20 14:08:28 +08:00
Mingqiang Chi 74849cd983 modulization:move out efi dir from hypervisor
move acrn-hypervisor/hypervisor/bsp/uefi/efi
to   arcn-hypervisor/efi-stub
move acrn-hypervisor/hypervisor/bsp/uefi/clearlinux
to   acrn-hypervisor/efi-stub/clearlinux

Changes to be committed:
  modified:   Makefile
  modified:   doc/getting-started/apl-nuc.rst
  renamed:    hypervisor/bsp/uefi/efi/Makefile -> efi-stub/Makefile
  renamed:    hypervisor/bsp/uefi/efi/boot.c -> efi-stub/boot.c
  renamed:    hypervisor/bsp/uefi/efi/boot.h -> efi-stub/boot.h
  renamed:    hypervisor/bsp/uefi/clearlinux/acrn.conf ->
	      efi-stub/clearlinux/acrn.conf
  renamed:    hypervisor/bsp/uefi/efi/efilinux.h -> efi-stub/efilinux.h
  renamed:    hypervisor/bsp/uefi/efi/malloc.c -> efi-stub/malloc.c
  renamed:    hypervisor/bsp/uefi/efi/multiboot.h -> efi-stub/multiboot.h
  renamed:    hypervisor/bsp/uefi/efi/pe.c -> efi-stub/pe.c
  renamed:    hypervisor/bsp/uefi/efi/stdlib.h -> efi-stub/stdlib.h
  modified:   hypervisor/Makefile

Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
2018-12-17 15:46:23 +08:00