The current config.mk uses the variable BOARD_FILE as the path to the board
XML when generating an unmodified copy of configuration files for
comparison, which is incorrect. The right variable is HV_BOARD_XML which is
the path to the copy of board XML that is actually used for the build.
This patch corrects the bug above.
In addition, this patch also skips binary files (which are not meant to be
edited manually) when calculating the differences.
Tracked-On: #6592
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Before checking whether a PCI device is a Multi-Function Device or not, we need
make sure this PCI device is a valid PCI device. For a valid PCI device, the
'Header Layout' field in Header Type Register must be 000 0000b (Type 0 PCI device)
or 000 0001b (Type 1 PCI device).
So for a valid PCI device, the Header Type can't be 0xff.
Tracked-On: #4134
Signed-off-by: Fei Li <fei1.li@intel.com>
Add a couple of missing dependencies in the ACRN Makefiles:
1. 'acrn.bin' is required before the hypervisor can be installed
2. The 'acrn_mngr.h' needs to be installed ('tools-install') in
the build folder.
Tracked-On: #6360
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
On some UEFI platforms, it is found that SMBIOS major version 3 can be
found under SMBIOS2 GUID, so using major version to distinguish
different version of SMBIOS is not reliable. This patch removes the use
of smbios_info.major_ver, and checks the anchor string instead.
Tracked-On: #6528
Signed-off-by: Yifan Liu <yifan1.liu@intel.com>
In current design, when pass-thru dev,
for the PIO bar, need to ensure the guest PIO start address
equals to host PIO start address.
Then set the VMCS io bitmap to pass-thru the corresponding
port io to guest for performance.
But malicious guest may reprogram the PIO bar,
then hv will pass-thru the reprogramed PIO address to guest.
This isn't safe behavior.
Here only pass-thru the host physical device PIO to guest.
If guest regrogram the PIO bar, just update the virtual bar only.
Currently, we don't support PIO bar reprogramming,
if guest reprogram the PIO bar, guest should take responsibility itself
When init the pass-thru dev PIO bars, set the VMCS io bitmap.
setup_io_bitmap is called before init pass-thru dev to
initiailize the io bitmap, so don't need to
call deny_guest_pio_access when deinit pass-thru dev.
v1 -> v2:
* set the VMCS io bitmap when init pass-thru devices
to migrate redoing allow_guest_pio_access()/deny_guest_pio_access().
Tracked-On: #6508
Signed-off-by: Liu,Junming <junming.liu@intel.com>
consistent
Currently the vcpu_make_request and signal_event in vcpu_lock_instr_emulation
does not check whether target VCPU is up and running. This can cause
problems because when VCPU is created but not launched,
vcpu_make_request will not trigger wait_event on target VCPU, but
signal_event may still execute to reduce the counter.
This patch adds a check before vcpu_make_request and signal_event to
make sure the request and signal are issued after target VCPU is up.
Tracked-On: #6502
Signed-off-by: Yifan Liu <yifan1.liu@intel.com>
The length of the ACPI data entry in ve820 tab was 960K, while the
ACPI file is 1MB. It would cause ept unmapped fault when loading the
pre-launched VMs. This patch changes it to 1MB to fix the problem.
And the ACPI data length was missed when calculating
ENTRY_HPA1_LOW_PART2 length. Fixed here too.
The vACPI data and NVS entry size for pre-launched VM is currently
hard-coded. Add VIRT_ACPI_DATA_LEN and VIRT_ACPI_NVS_LEN to replace
them. And build connection with their starting address, too.
Tracked-On: #6507
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Reviewed-by: Victor Sun <victor.sun@intel.com>
For platforms that do not support XSAVES/XRSTORS instructions, like QEMU,
executing these instructions causes #UD.
This patch adds the check before the execution of XSAVES/XRSTORS instructions.
It also refines the logic inside rstore_xsave_area for the following reason:
If XSAVES/XRSTORS instructions are supported, restore XSAVE area if any of the
following conditions is met:
1. "vcpu->launched" is false (state initialization for guest)
2. "vcpu->arch.xsave_enabled" is true (state restoring for guest)
* Before vCPU is launched, condition 1 is satisfied.
* After vCPU is launched, condition 2 is satisfied because
is_valid_xsave_combination() guarantees that "vcpu->arch.xsave_enabled"
is consistent with pcpu_has_cap(X86_FEATURE_XSAVES).
Therefore, the check against "vcpu->launched" and "vcpu->arch.xsave_enabled"
can be eliminated here.
Tracked-On: #6481
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
In ACRN RT VM if the lapic is passthrough to the guest, the ipi can't
trigger VM_EXIT and the vNMI is just for notification, it can't handle
the smp_call function. Modify vcpu_dumpreg function prompt user switch
to vLAPIC mode for vCPU register dump.
Tracked-On: #6473
Signed-off-by: Liu Long <long.liu@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
GSI of hcall_set_irqline should be checked against target_vm's
total GSI count instead of SOS's total GSI count.
Tracked-On: #6357
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
This feature is guarded under config CONFIG_SECURITY_VM_FIXUP, which
by default should be disabled.
This patch passthrough native SMBIOS information to prelaunched VM.
SMBIOS table contains a small entry point structure and a table, of which
the entry point structure will be put in 0xf0000-0xfffff region in guest
address space, and the table will be put in the ACPI_NVS region in guest
address space.
v2 -> v3:
uuid_is_equal moved to util.h as inline API
result -> pVendortable, in function efi_search_guid
recalc_checksum -> generate_checksum
efi_search_smbios -> efi_search_smbios_eps
scan_smbios_eps kept (checked with Shiqing)
EFI GUID definition kept
Tracked-On: #6320
Signed-off-by: Yifan Liu <yifan1.liu@intel.com>
This patch renames the GUEST_FLAG_TPM2_FIXUP to
GUEST_FLAG_SECURITY_VM.
v2 -> v3:
The "FIXUP" suffix is removed.
Tracked-On: #6320
Signed-off-by: Yifan Liu <yifan1.liu@intel.com>
Oops
It is used to specify the maximum number of EFI memmap entries.
On some platforms, like Tiger Lake, the number of EFI memmap entries
becomes 268 when the BIOS settings are changed.
The current value of MAX_EFI_MMAP_ENTRIES (256) defined in hypervisor
is not big enough to cover such cases.
As the number of EFI memmap entries depends on the platforms and the
BIOS settings, this patch introduces a new entry MAX_EFI_MMAP_ENTRIES
in configurations so that it can be adjusted for different cases.
Tracked-On: #6442
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
If SOS is using kernel 5.4, hypervisor got panic with #GP.
Here is an example on KBL showing how the panic occurs when kernel 5.4 is used:
Notes:
* Physical MSR_IA32_XSS[bit 8] is 1 when physical CPU boots up.
* vcpu_get_guest_msr(vcpu, MSR_IA32_XSS)[bit 8] is initialized to 0.
Following thread switches would happen at run time:
1. idle thread -> vcpu thread
context_switch_in happens and rstore_xsave_area is called.
At this moment, vcpu->arch.xsave_enabled is false as vcpu is not launched yet
and init_vmcs is not called yet (where xsave_enabled is set to true).
Thus, physical MSR_IA32_XSS is not updated with the value of guest MSR_IA32_XSS.
States at this point:
* Physical MSR_IA32_XSS[bit 8] is 1.
* vcpu_get_guest_msr(vcpu, MSR_IA32_XSS)[bit 8] is 0.
2. vcpu thread -> idle thread
context_switch_out happens and save_xsave_area is called.
At this moment, vcpu->arch.xsave_enabled is true. Processor state is saved
to memory with XSAVES instruction. As physical MSR_IA32_XSS[bit 8] is 1,
ectx->xs_area.xsave_hdr.hdr.xcomp_bv[bit 8] is set to 1 after the execution
of XSAVES instruction.
States at this point:
* Physical MSR_IA32_XSS[bit 8] is 1.
* vcpu_get_guest_msr(vcpu, MSR_IA32_XSS)[bit 8] is 0.
* ectx->xs_area.xsave_hdr.hdr.xcomp_bv[bit 8] is 1.
3. idle thread -> vcpu thread
context_switch_in happens and rstore_xsave_area is called.
At this moment, vcpu->arch.xsave_enabled is true. Physical MSR_IA32_XSS is
updated with the value of guest MSR_IA32_XSS, which is 0.
States at this point:
* Physical MSR_IA32_XSS[bit 8] is 0.
* vcpu_get_guest_msr(vcpu, MSR_IA32_XSS)[bit 8] is 0.
* ectx->xs_area.xsave_hdr.hdr.xcomp_bv[bit 8] is 1.
Processor state is restored from memory with XRSTORS instruction afterwards.
According to SDM Vol1 13.12 OPERATION OF XRSTORS, a #GP occurs if XCOMP_BV
sets a bit in the range 62:0 that is not set in XCR0 | IA32_XSS.
So, #GP occurs once XRSTORS instruction is executed.
Such issue does not happen with kernel 5.10. Because kernel 5.10 writes to
MSR_IA32_XSS during initialization, while kernel 5.4 does not do such write.
Once guest writes to MSR_IA32_XSS, it would be trapped to hypervisor, then,
physical MSR_IA32_XSS and the value of MSR_IA32_XSS in vcpu->arch.guest_msrs
are updated with the value specified by guest. So, in the point 2 above,
correct processor state is saved. And #GP would not happen in the point 3.
This patch initializes the XSAVE related processor state for guest.
If vcpu is not launched yet, the processor state is initialized according to
the initial value of vcpu_get_guest_msr(vcpu, MSR_IA32_XSS), ectx->xcr0,
and ectx->xs_area. With this approach, the physical processor state is
consistent with the one presented to guest.
Tracked-On: #6434
Signed-off-by: Shiqing Gao <shiqing.gao@intel.com>
Reviewed-by: Li Fei1 <fei1.li@intel.com>
Since previous patch to enlarge ACPI NVS/Data region from
960K(reclaim)/64K(NVS) to 960K(reclaim)/1M(NVS), some hard-coded
constants in create_prelaunched_vm_e820 were left unchanged.
This may results in failure to map the ACPI NVS region because the
remaining memory size was wrong.
This patch updates the constants and comments of function
create_prelaunched_vm_e820.
Tracked-On: #6423
Signed-off-by: Yifan Liu <yifan1.liu@intel.com>
MAXIMUM_PA_WIDTH will be calculated from board information.
Tracked-On: #6357
Signed-off-by: Liang Yi <yi.liang@intel.com>
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Mask off support of 57-bit linear addresses and five-level paging.
ICX-D has LA57 but ACRN doesn't support 5-level paging yet.
Tracked-On: #6357
Signed-off-by: Liang Yi <yi.liang@intel.com>
Signed-off-by: Li, Fei1 <fei1.li@intel.com>
Currently the sched event handling may encounter data race problem, and
as a result some vcpus might be stalled forever.
One example can be wbinvd handling where more than 1 vcpus are doing
wbinvd concurrently. The following is a possible execution of 3 vcpus:
-------
0 1 2
req [Note: 0]
req bit0 set [Note: 1]
IPI -> 0
req bit2 set
IPI -> 2
VMExit
req bit2 cleared
wait
vcpu2 descheduled
VMExit
req bit0 cleared
wait
vcpu0 descheduled
signal 0
event0->set=true
wake 0
signal 2
event2->set=true [Note: 3]
wake 2
vcpu2 scheduled
event2->set=false
resume
req
req bit0 set
IPI -> 0
req bit1 set
IPI -> 1
(doesn't matter)
vcpu0 scheduled [Note: 4]
signal 0
event0->set=true
(no wake) [Note: 2]
event0->set=false (the rest doesn't matter)
resume
Any VMExit
req bit0 cleared
wait
idle running
(blocked forever)
Notes:
0: req: vcpu_make_request(vcpu, ACRN_REQUEST_WAIT_WBINVD).
1: req bit: Bit in pending_req_bits. Bit0 stands for bit for vcpu0.
2: In function signal_event, At this time the event->waiting_thread
is not NULL, so wake_thread will not execute
3: eventX: struct sched_event of vcpuX.
4: In function wait_event, the lock does not strictly cover the execution between
schedule() and event->set=false, so other threads may kick in.
-----
As shown in above example, before the last random VMExit, vcpu0 ended up
with request bit set but event->set==false, so blocked forever.
This patch proposes to change event->set from a boolean variable to an
integer. The semantic is very similar to a semaphore. The wait_event
will add 1 to this value, and block when this value is > 0, whereas signal_event
will decrease this value by 1.
It may happen that this value was decreased to a negative number but that
is OK. As long as the wait_event and signal_event are paired and
program order is observed (that is, wait_event always happens-before signal_event
on a single vcpu), this value will eventually be 0.
Tracked-On: #6405
Signed-off-by: Yifan Liu <yifan1.liu@intel.com>
This is a simply implement for the 32bit and 64bit elf loader.
The loading function first reads the image header, and finds the program
entries that are marked as PT_LOAD, then loads segments from elf file to
guest ram. After that, it finds the bss section in the elf section entries, and
clear the ram area it points to.
Limitations:
1. The e_type of the elf image must be ET_EXEC(executable). Relocatable or
dynamic code is not supported.
2. The loader only copies program segments that has a p_type of
PT_LOAD(loadable segment). Other segments are ignored.
3. The loader doesn’t support Sections that are relocatable
(sh_type is SHT_REL or SHT_RELA)
4. The 64bit elf’s entry address must below 4G.
5. The elf is assumed to be able to put segments to valid guest memory.
Tracked-On: #6323
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
This patch adds a function elf_loader() to load elf image.
It checks the elf header, get its 32/64 bit type, then calls
the corresponding loading routines, which are empty, and
will be realized later.
Tracked-On: #6323
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Source: https://github.com/freebsd/freebsd-src/blob/main/sys/sys/elf_common.h
Trimed to meet the minimal requirements for the Zephyr elf file to be loaded
Also added elf file header data struct and program/section entry data structs.
Tracked-On: #6323
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Reviewed-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
In order to make better sense, vm_elf_loader, vm_bzimage_loader and
vm_rawimage_loader are changed to elf_loaer, bzimage_loaer and
rawimage_loader.
Tracked-On: #6323
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Remove the acpi loading function from elf_loader, rawimage_loaer and
bzimage_loader, and call it together in vm_sw_loader.
Now the vm_sw_loader's job is not just loading sw, so we rename it to
prepare_os_image.
Tracked-On: #6323
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Reviewed-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
For the guest OS loaders, prapare_loading_xxx are not accurate for
what those functions actually do. Now they are changed to load_xxx:
load_rawimage, load_bzimage.
And the 'bsp' expression is confusing in the comments for
init_vcpu_protect_mode_regs, changed to a better way.
Tracked-On: #6323
Signed-off-by: Zhou, Wu <wu.zhou@intel.com>
Reviewed-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
vboot_info.h declares vm loader function also, so rename the file name to
vboot.h;
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The patch splits the vm_load.c to three parts, the loader function of bzImage
kernel is moved to bzimage_loader.c, the loader function of raw image kernel
is moved to rawimage_loader.c, the stub is still stayed in vm_load.c to load
the corresponding kernel loader function. Each loader function could be
isolated by CONFIG_GUEST_KERNEL_XXX macro which generated by config tool.
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Change if condition to switch in vm_sw_loader() so that the sw loader
could be compiled conditionally.
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Rename KERNEL_ZEPHYR to KERNEL_RAWIMAGE. Added new type "KERNEL_ELF".
Add CONFIG_GUEST_KERNEL_RAWIMAGE, CONFIG_GUEST_KERNEL_ELF and/or
CONFIG_GUEST_KERNEL_BZIMAGE to config.h if it's configured.
Tracked-On: #6323
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Victor Sun <victor.sun@intel.com>
Previously we only support loading raw format of zephyr image as prelaunched
Zephyr VM, this would cause guest F segment overridden issue because the zephyr
raw image covers memory space from 0x1000 to 0x100000 upper. To fix this issue,
we should support ELF format image loading so that parse and load the multiple
segments from ELF image directly.
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
ACRN does not support the variable range vMTRR. The default
memory type of vMTRR is UC. With this vMTRR emulation guest VM
such as Linux refuses to map the MMIO address space as WB. In
order to get better performance SHM BAR of ivshmem is mapped
with PAT ignored and memory type of SHM BAR is fixed to WB.
Tracked-On: #6389
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Create virtual acpi table of tpm2 based on the raw data if the TPM2
device is presented and the passthrough tpm2 is enabled.
Refine the arguments of bin_gen.py. The --board and --scenario take the
path to the XMLs as the argument. The allocation.xml is needed for
bin_gen.py to generate tpm2 acpi table.
Refine the condition of tpm2_acpi_gen. The tpm2 device "MSFT0101" can be
present in device id or compatible_id(CID). Check both attributes and
child node of tpm2 device.
Tracked-On: #6320
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Relocate ACPI address to 0x7fe00000 and ACPI NVS to 0x7ff00000 correspondingly.
In this case, we could include TPM event log region [0x7ffb0000, 0x80000000)
into ACPI NVS.
Tracked-On: #6320
Signed-off-by: Fei Li <fei1.li@intel.com>
ACRN used to prepare the vTPM2 ACPI Table for pre-launched VM at the build stage
using config tools. This is OK if the TPM2 ACPI Table never changes. However,
TPM2 ACPI Table may be changed in some conditions: change BIOS configuration or
update BIOS.
This patch do TPM2 fixup to update the vTPM2 ACPI Table and TPM2 MMIO resource
configuration according to the physical TPM2 ACPI Table.
Tracked-On: #6366
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Signed-off-by: Fei Li <fei1.li@intel.com>
1. add a name field to indicate what the MMIO Device is.
2. add two more MMIO resource to the acrn_mmiodev data structure.
Tracked-On: #6366
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
Signed-off-by: Fei Li <fei1.li@intel.com>
ACRN could run without XSAVE Capability. So remove XSAVE dependence to support
more (hardware or virtual) platforms.
Tracked-On: #6287
Signed-off-by: Fei Li <fei1.li@intel.com>
Check whether condition is met before check whether time is out after iommu_read32.
This is because iommu_read32 would cause time out on some virtual platform in
spite of the current DMAR status meets the pre_condition.
Tracked-On: #6371
Signed-off-by: Fei Li <fei1.li@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
If HV enable trigger #GP for uc-lock, and is about to emulate guest uc-lock
instructions, should trap guest #GP. Guest uc-lock instrucction trigger #GP,
cause vmexit for #GP, HV handle this vmexit and emulate uc-lock
instruction.
Tracked-On: #6299
Signed-off-by: Tao Yuhong <yuhong.tao@intel.com>
User could use make targz-pkg command to generate tar package in
build directory,which could help user simplify the process
of installing acrn hypervisor in target board. user need to copy the
tarball package to target board,and extract it to "/" directory.
Tracked-On: #6355
Signed-off-by: liu hang1 <hang1.liu@intel.com>
Reviewed-by: VanCutsem, Geoffroy <geoffroy.vancutsem@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Currently the HV console does not support PCI UART with 64bit BAR, but in the
case that the BAR is in 64bit and the BAR space is below 4GB (i.e. the high
32bit address of the 64bit BAR is zero), HV should be able to support it.
Tracked-On: #6334
Signed-off-by: Victor Sun <victor.sun@intel.com>
When guest kernel has multiple loading segments like ELF format image, just
define one load address in sw_kernel_info struct is meaningless.
The patch removes kernel_load_addr member in struct sw_kernel_info, the load
address should be parsed in each specified format image processing.
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
The previous code did not load bzImage start from protected mode part, result
in the protected mode part un-align with kernel_alignment field and then cause
kernel decompression start from a later aligned address. In this case we had
to enlarge the needed size of bzImage kernel to kernel_init_size plus double
size of kernel_alignment.
With loading issue of bzImage protected mode part fixed, the kernel needed size
is corrected in this patch.
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
When LaaG boots with bzImage module file, only protected mode code need
to be loaded to guest space since the VM will boot from protected mode
directly. Futhermore, per Linux boot protocol the protected mode code
better to be aligned with kernel_alignment field in zeropage, otherwise
kernel will take time to do "rep movs" to the aligned address.
In previous code, the bzImage is loaded to the address where aligned with
kernel_alignment, this would make the protected mode code unalign with
kernel_alignment. If the kernel is configured with CONFIG_RELOCATABLE=n,
the guest would not boot. This patch fixed this issue.
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
This patch moves get_bzimage_kernel_load_addr() from init_vm_sw_load() to
vm_sw_loader() stage so will set kernel load address of bzImage type kernel
in vm_bzimage_loader() in vm_load.c.
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
This patch moves get_initrd_load_addr() API from init_vm_sw_load() to
vm_sw_loader() stage. The patch assumes that the kernel image have been
loaded to guest space already.
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
In load_sw_modules() implementation, we always assuming the guest kernel
module has one load address and then the whole kernel image would be loaded
to guest space from its load address. This is not true when guest kernel
has multiple load addresses like ELF format kernel image.
This patch removes load_sw_modules() API, and the loading method of each
format of kernel image could be specified in prepare_loading_xxximage() API.
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
As the previous commit said the kernel load address should be moved
from init_vm_sw_load() to vm_sw_loader() stage. This patch refines
the API of get_bzimage_kernel_load_addr() in init_vm_kernel_info()
for later use.
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Currently the guest kernel load address and ramdisk load address are
initialized during init_vm_sw_load() stage, this is meaningless when
guest kernel has multiple segments with different loading addresses.
In that case, the kernel load addresses should be parsed and loaded
in vm_sw_loader() stage, the ramdisk load address should be set in
that stage also because it is depended on kernel load address.
This patch refines the API of get_initrd_load_addr() which will set
proper initrd load address of bzImage type kernel for later use.
Tracked-On: #6323
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
