In current implementation, if there are multiple continous 4k-aligned
modules, 0-sized e820 entries will be created between these regions.
And for non-4k-aligned modules, when two of them are located in one
page, the second memory range will not be reserved as it was not in
one e820 entry after the first is reserved, making it vulnerable.
This patch fixes it by marking the exact memory range of multiboot
modules as unusable first, then shrinking the e820 entries to page
boundary. If the module crosses multiple e820 entries, possibly due
to a buggy bootloader, hypervisor will panic immediately to prevent
modules getting corrupted.
Tracked-On: #8617
Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Modified the copyright year range in code, and corrected "int32_tel"
into "Intel" in two "hypervisor/include/debug/profiling.h" and
"hypervisor/include/debug/profiling_internal.h".
Tracked-On: #7559
Signed-off-by: Ziheng Li <ziheng.li@intel.com>
Many of the license and Intel copyright headers include the "All rights
reserved" string. It is not relevant in the context of the BSD-3-Clause
license that the code is released under. This patch removes those strings
throughout the code (hypervisor, devicemodel and misc).
Tracked-On: #7254
Signed-off-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
The e820 module could get the RAM info on run time, but the RAM size
and MAX address was limited by CONFIG_PLATFORM_RAM_SIZE which was
predefined by config tool.
Current solution can't support single binary for different boards or
platforms and the CONFIG_PLATFORM_RAM_SIZE can't matching the RAM size
if user have not update config tools setting after the device changed.
So this patch remove the CONFIG_PLATFORM_RAM_SIZE and calculate ram
size on run time.
Tracked-On: #6690
Acked-by: Anthony Xu <anthony.xu@intel.com>
Signed-off-by: Chenli Wei <chenli.wei@linux.intel.com>
Sometimes the memory to be allocated is not at the end of an entry,
that means we have to break one enty into 2 smaller entries, there
are two ways to add the new entry to hv_e820, adds to the end or
insert it.
The initial e820 table is ordered, that's why the e820_alloc_memory
interface asssum all entries was sorted, but add new entry to the
end will break the orde of hv_e820.
So we use insert_e820_entry to replace the add_e820_entry, the new
interfeac will keep the orde and users do not need sort again after
alloc region
Tracked-On: #6690
Acked-by: Anthony Xu <anthony.xu@intel.com>
Signed-off-by: Chenli Wei<chenli.wei@linux.intel.com>
Now the multiboot modules memory have not reserve,it's an issue if
these memory alloc and write before VM start.
Incorrect allocation of multiboot modules memory will cause VM lost
data or start faild.
So we find these modules memory range and reserve these memory from
e820 entry.
All these memory will realloc to VM which own them before the vm start.
Tracked-On: #6690
Acked-by: Anthony Xu <anthony.xu@intel.com>
Signed-off-by: Chenli Wei <chenli.wei@intel.com>
e820_alloc_memory requires 4k alignment, so conversion to size is
encapsulated in the function. And then the pre-condition of
`size_arg` is removed.
Tracked-On: #6805
Signed-off-by: Yuanyuan Zhao <yuanyuan.zhao@linux.intel.com>
Reviewed-by: Wang, Yu1 <yu1.wang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Rename sos_vm to service_vm.
rename sos_vmid to service_vmid.
rename sos_vm_ptr to service_vm_ptr.
rename get_sos_vm to get_service_vm.
rename sos_vm_gpa to service_vm_gpa.
rename sos_vm_e820 to service_vm_e820.
rename sos_efi_info to service_vm_efi_info.
rename sos_vm_config to service_vm_config.
rename sos_vm_hpa2gpa to service_vm_hpa2gpa.
rename vdev_in_sos to vdev_in_service_vm.
rename create_sos_vm_e820 to create_service_vm_e820.
rename sos_high64_max_ram to service_vm_high64_max_ram.
rename prepare_sos_vm_memmap to prepare_service_vm_memmap.
rename post_uos_sworld_memory to post_user_vm_sworld_memory
rename hcall_sos_offline_cpu to hcall_service_vm_offline_cpu.
rename filter_mem_from_sos_e820 to filter_mem_from_service_vm_e820.
rename create_sos_vm_efi_mmap_desc to create_service_vm_efi_mmap_desc.
rename HC_SOS_OFFLINE_CPU to HC_SERVICE_VM_OFFLINE_CPU.
rename SOS to Service VM in comments message.
Tracked-On: #6744
Signed-off-by: Liu Long <long.liu@linux.intel.com>
Reviewed-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
Hypervisor use e820_alloc_memory() api to allocate memory for trampoline code
and ept pages, whereas the usable ram in hv_e820 might include efi boot service
region if system boot from uefi environment, this would result in some uefi
service broken in SOS. These boot service region should be filtered from
hv_e820.
This patch will parse the efi memory descriptor entries info from efi memory
map pointer when system boot from uefi environment, and then initialize hv_e820
accordingly, that all efi boot service region would be kept as reserved in
hv_e820.
Please note the original efi memory map could be above 4GB address space,
so the efi memory parsing process must be done after enable_paging().
Tracked-On: #5626
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Use more generic abi_mmap struct to replace multiboot_mmap struct in
acrn_boot_info;
Tracked-On: #5661
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Given the structure in multiboot.h could be used for any boot protocol,
use a more generic name "boot.h" instead;
Tracked-On: #5661
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
The acrn_multiboot_info structure stores acrn specific boot info and should
not be limited to support multiboot protocol related structure only.
This patch only do below changes:
1. change name of acrn_multiboot_info to acrn_boot_info;
2. change name of mbi to abi because of the change in 1, also the
naming might bring confusion with native multiboot info;
Tracked-On: #5661
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Instead of "#include <x86/foo.h>", use "#include <asm/foo.h>".
In other words, we are adopting the same practice in Linux kernel.
Tracked-On: #5920
Signed-off-by: Liang Yi <yi.liang@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
No one uses get_mem_range_info to get the top/bottom/size of the physical memory.
We could get these informations by e820 table easily.
Tracked-On: #5830
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Acked-by: eddie Dong <eddie.dong@intel.com>
Requires explicit arch path name in the include directive.
The config scripts was also updated to reflect this change.
Tracked-On: #5825
Signed-off-by: Peter Fang <peter.fang@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Current memory allocation algorithm is to find the available address from
the highest possible address below max_address. If the function returns 0,
means all memory is used up and we have to put the resource at address 0,
this is dangerous for a running hypervisor.
Also returns 0 would make code logic very complicated, since memcpy_s()
doesn't support address 0 copy.
Tracked-On: #5626
Signed-off-by: Victor Sun <victor.sun@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
The init_multiboot_info() and sanitize_multiboot_ifno() APIs now
require parameters instead of implicitly relying on global boot
variables.
Tracked-On: #5661
Signed-off-by: Vijay Dhanraj <vijay.dhanraj@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Move multiboot specific declarations from boot.h to multiboot.h.
Tracked-On: #5661
Signed-off-by: Vijay Dhanraj <vijay.dhanraj@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@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>
It puts the new line in the wrong place, and the logs are confusing.
For example, for these entries:
mmap[0] - type: 1, base: 0x00000, length: 0x9800
mmap[1] - type: 2, base: 0x98000, length: 0x8000
mmap[2] - type: 3, base: 0xc0000, length: 0x4000
Currently it prints them in this way:
mmap table: 0 type: 0x1
Base: 0x0000000000000000 length: 0x0000000000098000
mmap table: 1 type: 0x2
Base: 0x0000000000098000 length: 0x0000000000008000
mmap table: 2 type: 0x3
Base: 0x00000000000c0000 length: 0x0000000000040000
With this fix, it looks like the following, and now it's of same style
with how prepare_sos_vm_memmap() logs ve820 tables.
mmap table: 0 type: 0x1
Base: 0x0000000000000000 length: 0x0000000000098000
mmap table: 1 type: 0x2
Base: 0x0000000000098000 length: 0x0000000000008000
mmap table: 2 type: 0x3
Base: 0x00000000000c0000 length: 0x0000000000040000
Tracked-On: #1842
Signed-off-by: Zide Chen <zide.chen@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>
Now the default board memory size is 16 GB. However, ACRN support more and more boards
which may have memory size large than 16 GB. This patch try to filter e820 table which
is over top address space.
Tracked-On: #4007
Signed-off-by: Li Fei1 <fei1.li@intel.com>
Now the e820 structure store ACRN HV memory layout, not the physical memory layout.
Rename e820 to hv_hv_e820 to show this explicitly.
Tracked-On: #4007
Signed-off-by: Li Fei1 <fei1.li@intel.com>
The init page tables installed in either cpu_primary.S or trampoline.S
are 1:1 mapping and won't be changed in the future.
The 'actual' hypervisor page table installed in enable_paging() is 1:1
mapping currently but it could be changed in the future. Both hva2hpa() and
hpa2hva() are implemented based on these page tables and can't be used
when the init page tables take effect.
This patch does the following cleanup:
- remove all hva2hpa()/hpa2hva() before calling enable_paging()
- get_hv_image_base() returns HVA, not HPA. So add hva2hpa() for all cases
that are called afte enable_paging().
Tracked-On: #2700
Signed-off-by: Zide Chen <zide.chen@intel.com>
Acked-by: Eddie Dong <Eddie.dong@intel.com>
Remove redundancy code since they are not used now.
-- remove 'max_ram_blk_base' & 'max_ram_blk_size' in
struct e820_mem_params
-- remove 'gpa_lowtop' in struct vm_hw_info
-- remove MACRO 'UOS_DEFAULT_START_ADDR'
Tracked-On: #1842
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
- add e820 info in struct acrn_vm;
- rename rebuild_sos_vm_e820() to create_sos_vm_e820();
- add create_prelaunched_vm_e820() for partition mode;
- rename create_e820_table() to create_zeropage_e820() and merge for
both sharing mode and partition mode;
- move create_xxx_vm_e820() to vm.c;
- move create_zeropage_e820() to vm_load.c;
Tracked-On: #2291
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
move e820_default_entries[] from vm_description.c to ve820.c and rename
to ve820_entry[] as a temparary solution for partiton mode e820 management;
Tracked-On: #2291
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Under sharing mode, VM0 is identical with SOS VM. But the coupling of
SOS VM and VM 0 is not friendly for partition mode.
This patch is a pure term change of vm0 to sos VM, it does not change
any code logic or senmantic.
Tracked-On: #2291
Signed-off-by: Victor Sun <victor.sun@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
1. change its APIs as more indepentent, and modify the callers' code
2. limit its global variables as static, and return const to the callers
3. remove unused code in "CONFIG_CMA"
Tracked-On: #1842
Signed-off-by: Minggui Cao <minggui.cao@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
1. e820 is modulized as separated files.
2. move boot_regs into multiboot.h as it's related with
multiboot info header
Tracked-On: #1842
Signed-off-by: Minggui Cao <minggui.cao@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
