Previously the VM kernel bootargs for pre-launched VMs and direct boot mode
of SOS VM are built-in hypervisor binary so end users have no way to change
it. Now we provide another option that the multiboot module string could be
used as bootargs also. This would bring convenience to end users when they
use GRUB as bootloader because the bootargs could be configurable in GRUB
menu.
The usage is if there is any string follows configured kernel_mod_tag in
module string, the string will be used as new kernel bootargs instead of
built-in kernel bootargs. If there is no string follows kernel_mod_tag,
then the built-in bootargs will be the default kernel bootargs.
Please note kernel_mod_tag must be the first word in module string in any
case, it is used to specify the module for which VM.
Tracked-On: #4885
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
Previously append_seed_arg() just do fill in seed arg to dest cmd buffer,
so rename the api name to fill_seed_arg().
Since fill_seed_arg() will be called in SOS VM path only, the param of
bool vm_is_sos is not needed and will be replaced by dest buffer size.
The seed_args[] which used by fill_seed_arg() is pre-defined as all-zero,
so memset() is not needed in fill_seed_arg(), buffer pointer check
and strncpy_s() are not needed also.
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>
Add a standard string api strncat_s() to replace merge_cmdline() to make code
more readable.
Another change is that the multiboot cmdline will be appended to the end of
configured SOS bootargs instead of the beginning, this would enable a feature
that some kernel cmdline paramter items could be overriden by multiboot cmdline
since the later one would win if same parameters configured in kernel cmdline.
Tracked-On: #4885
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
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>
As ACRN prepares to support servers with large amounts of memory
current logic to allocate space for 4K pages of EPT at compile time
will increase the size of .bss section of ACRN binary.
Bootloaders could run into a situation where they cannot
find enough contiguous space to load ACRN binary under 4GB,
which is typically heavily fragmented with E820 types Reserved,
ACPI data, 32-bit PCI hole etc.
This patch does the following
1) Works only for "direct" mode of vboot
2) reserves space for 4K pages of EPT, after boot by parsing
platform E820 table, for all types of VMs.
Size comparison:
w/o patch
Size of DRAM Size of .bss
48 GB 0xe1bbc98 (~226 MB)
128 GB 0x222abc98 (~548 MB)
w/ patch
Size of DRAM Size of .bss
48 GB 0x1991c98 (~26 MB)
128 GB 0x1a81c98 (~28 MB)
Tracked-On: #4563
Signed-off-by: Sainath Grandhi <sainath.grandhi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
- 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>
Initialize module info and ACPI rsdp info of acrn mbi when boot from
multiboot2 protocol, with this patch SOS VM could be loaded sucessfully
with correct ACPI RSDP;
Tracked-On: #4419
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
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>
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>
1. Rename BOOT_CPU_ID to BSP_CPU_ID
2. Repace hardcoded value with BSP_CPU_ID when
ID of BSP is referenced.
Tracked-On: #4420
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
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>
Currently, memory with size of 'CONFIG_LOW_RAM_SIZE' will be
allocated when 'get_direct_boot_ap_trampoline()' is called.
This patch refine the implementation of of above function, it
returns the base address of trampoline buffer when called, and
the memory is allocated when vboot module is initialized.
Tracked-On: #3992
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Fei Li <fei1.li@intel.com>
With cpu sharing enabled, per_cpu vcpu cannot work properly as we might
has multiple vcpus running on one pcpu.
Add a schedule API sched_get_current to get current thread_object on
specific pcpu, also add a vcpu API get_running_vcpu to get corresponding
vcpu of the thread_object.
Tracked-On: #3813
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Signed-off-by: Yu Wang <yu1.wang@intel.com>
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
--remove unnecessary includes
--remove unnecssary forward-declaration for 'struct vhm_request'
Tracked-On: #861
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Enable uart as early as possible to make things easier for debugging.
After this we could use printf to output information to the uart. As for
pr_xxx APIs, they start to work when init_logmsg is called.
Tracked-On: #2987
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
In grub 2.02, the flag of MULTIBOOT_INFO_HAS_CMDLINE is set even there is
no cmdline was configured. So we need to validate the content of cmdline
in multiboot info. If there is no cmdline exist, we should not do merge
cmdline for SOS VM.
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
ACRN Coding guidelines requires type conversion shall be explicity.
Tracked-On: #861
Signed-off-by: Huihuang Shi <huihuang.shi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Fix the violations not touched the logical.
1.Function return value not checked.
2.Logical conjuctions need brackets.
3.No brackets to then/else.
4.Type conversion without cast.
Tracked-On: #861
Signed-off-by: Huihuang Shi <huihuang.shi@intel.com>
Zephyr kernel is stripped ram image, its entry and load address
are explicitly defined in vm configurations, hypervisor will load
Zephyr directly based on these configurations.
Currently we only support boot Zephyr from protected mode.
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Previously multiboot mods[0] is designed for kernel module for all
pre-launched VMs including SOS VM, and mods[0].mm_string is used
to store kernel cmdline. This design could not satisfy the requirement
of hybrid mode scenarios that each VM might use their own kernel image
also ramdisk image. To resolve this problem, we will use a tag in
mods mm_string field to specify the module type. If the tag could
be matched with os_config of VM configurations, the corresponding
module would be loaded;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Previously the bootargs of SOS_VM is stored in a text file and stitched
into multiboot mods[0].string whereas the bootargs of PRE_LAUNCHED_VM is
stored in vm_configurations.c. Given the mods[].string will be used to
store Kernel image signature under hybrid mode, move the bootargs of SOS_VM
to vm configurations also to make it consistent with PRE_LAUNCHED_VM;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Different kernel has different load method, it should be configurable
in vm configurations;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
For a Linux guest, the kernel load address should be gotten from zeropage
even for a pre-launched VM;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
The guest OS of ACRN will not be limited to Linux, so refine the struct
of sw_linux to more generic sw_module_info. Currently bootargs and ramdisk
are only supported modules but we can include more modules in future;
Tracked-On: #3214
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
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>
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>
remove some unnecessary includes,
some can cause reverse dependency.
Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
modified: acpi_parser/acpi_ext.c
modified: acpi_parser/dmar_parse.c
modified: boot/acpi_base.c
modified: boot/guest/direct_boot_info.c
modified: include/arch/x86/per_cpu.h
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>
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>
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>
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>
Victor Sun