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>
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>
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>
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>
- 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>
* 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>
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>
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>
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>
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>
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>
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>
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>
Jason Chen CJ