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>
The guest memory is allocated through hugetlb. Huge page fault is
triggered by writing a byte to the starting address for each huge page.
In hugetlb_fault(), The physical pages are allocated and *clear*.
So no need to erasing the memory again after hugetlb setup. This will
bring about 130ms (changes with platform) latency for each 1G memory.
Notice: this means we depends on kernel to erase the memory in huge page
fault!
Tracked-On: #7298
Signed-off-by: Conghui <conghui.chen@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@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 DMABuf sharing is based on the BLOB feature. This will
check the attribute of system memory for guest_vm and udmabuf.list_limit
parameter. If it meets with the requirement, export the BLOB feature
so that the FE driver in guest_vm can send the blob cmd.
VIRTIO_GPU_CMD_CREATE_BLOB:
VIRTIO_GPU_CMD_SET_SCANOUT_BLOB:
VIRTIO_GPU_CMD_SET_FLUSH(BLOB)
Tracked-On: #7210
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
After using the memfd to allocate memory for guest vm, it needs to
query the offset in memfd for the given GPA. In order to search the
memfd/offset, the added memory_region from memfd needs to be kept in
one arrary.
Tracked-On: #7210
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
The ACRN-DM uses the explicit hugetlb file to allocate the memory
for guest and the 2M/1G hugetlb can be used. This is based on mounting
hugetlb filesystem.
Now the Linux provides one flexbile memfd mechanism to allocate the memory
and this can make it possible to create the udmabuf for sharing. And the
memfd still can be based on Hugetlb 1G/2M policy. This can bring the below
benefits besides the 1G/2M hugetlb support.
a. memfd is based on anonymous file
b. possible dmabuf mechanism
v2->v3: After completing the mmap for memfd, it will call the ftruncate to
set the desired size and then add the F_SEAL_SEAL flag.
Tracked-On: #7210
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Now the memory region is aligned down to 2M if 2M hugetlb is supported.
Maybe some contents are dropped if it is not aligned.
Tracked-On: #7210
Acked-by: Wang Yu <yu1.wang@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Legacy VGA & VBE interface as a common interface is supported by
many legacy and modern OS. Many installer of OS distribution use
this interface to display the GUI of installer when setup a refresh
new installation on bare-metal. Besides, Windows OS always use this
interface to display it's BSOD, recovery mode & safe mode GUI. It
is need because Windows don't include virtio-gpu driver as their
in-box driver, VGA interface will be used before the virtio-gpu
driver been installed.
To be compatiable with the PCI bar layout of legacy VGA, the layout
is refined to meet with the requirement of legacy VGA and modern
virtio-gpu.
BAR0: VGA Framebuffer memory, 16 MB in size.
BAR2: MMIO Space
[0x0000~0x03ff] EDID data blob
[0x0400~0x041f] VGA ioports registers
[0x0500~0x0516] bochs display interface registers
[0x1000~0x17ff] Virtio common configuration registers
[0x1800~0x1fff] Virtio ISR state registers
[0x2000~0x2fff] Virtio device configuration registers
[0x3000~0x3fff] Virtio notification registers
BAR4: MSI/MSI-X
BAR5: Virtio port io
Tracked-On: #7210
Signed-off-by: Sun Peng <peng.p.sun@linux.intel.com>
Reviewed-by: Zhao, yakui <yakui.zhao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
The UUID has several usages before:
1, For HV to identify the static VM configuration of post-launched VM.
2, Seed virtualization.
3, Slightly prevent launching malicous VM from SOS as lack of secure
boot.
The UUID is confused to user, user don't understand what it is. And user
don't know where to get/apply the UUID. The worst experience is user
can't launch any VMs w/o re-compile the hv. Everything needs to be
static decided in building phase.
Now we decide to remove UUID and split each usage. For 1st usage, use
vmname as the identifier of static VM configuration. For 2nd one, we
will use --vseed as the new parameter. For 3rd one, will pretect by
SOS's dm-verity.
This patch will remove the UUID parameter and support 1st&3rd usages
from DM part. For 2nd usage, another patch will be submitted later.
Tracked-On: #6685
Signed-off-by: Yuanyuan Zhao <yuanyuan.zhao@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Rename SOS_VM_NUM to SERVICE_VM_NUM.
rename SOS_SOCKET_PORT to SERVICE_VM_SOCKET_PORT.
rename PROCESS_RUN_IN_SOS to PROCESS_RUN_IN_SERVICE_VM.
rename PCI_DEV_TYPE_SOSEMUL to PCI_DEV_TYPE_SERVICE_VM_EMUL.
rename SHUTDOWN_REQ_FROM_SOS to SHUTDOWN_REQ_FROM_SERVICE_VM.
rename PROCESS_RUN_IN_SOS to PROCESS_RUN_IN_SERVICE_VM.
rename SHUTDOWN_REQ_FROM_UOS to SHUTDOWN_REQ_FROM_USER_VM.
rename UOS_SOCKET_PORT to USER_VM_SOCKET_PORT.
rename SOS_CONSOLE to SERVICE_VM_OS_CONSOLE.
rename SOS_LCS_SOCK to SERVICE_VM_LCS_SOCK.
rename SOS_VM_BOOTARGS to SERVICE_VM_OS_BOOTARGS.
rename SOS_ROOTFS to SERVICE_VM_ROOTFS.
rename SOS_IDLE to SERVICE_VM_IDLE.
rename SEVERITY_SOS to SEVERITY_SERVICE_VM.
rename SOS_VM_UUID to SERVICE_VM_UUID.
rename SOS_REQ to SERVICE_VM_REQ.
rename RTCT_NATIVE_FILE_PATH_IN_SOS to RTCT_NATIVE_FILE_PATH_IN_SERVICE_VM.
rename CBC_REQ_T_UOS_ACTIVE to CBC_REQ_T_USER_VM_ACTIVE.
rename CBC_REQ_T_UOS_INACTIVE to CBC_REQ_T_USER_VM_INACTIV.
rename uos_active to user_vm_active.
Tracked-On: #6744
Signed-off-by: Liu Long <long.liu@linux.intel.com>
Reviewed-by: Geoffroy Van Cutsem <geoffroy.vancutsem@intel.com>
hugetlb_lv_max will get wrong value if the HUGETLB_LV2 mount failed.
Once hugetlb_lv_max is wrong, the following code logic messes up.
Tracked-On: #4937
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
use acrn-dm logger function instread of perror,
this helps the stability testing log capture.
Tracked-On: #4098
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Use acrn-dm logger function instread of printf,
this helps the stability testing log capture.
Tracked-On: #4098
Signed-off-by: Mingqiang Chi <mingqiang.chi@intel.com>
Reviewed-by: Cao Minggui <minggui.cao@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Lock should be held till all the mmap operations are done. This is to
avoid the mmap failure when multiple guests are created concurrently.
For example consider the following case in which vm1 and vm2 are
created by acrnd concurrently:
- vm1 is created with 4G+2M memory.
- 4G+2M memory is reserved in hugetlb now and vm1 continues to
allocate memory for the lowmem without lock held.
- 2G memory is allocated by vm1 for its lowmem, and 2G+2M memory
is available in hugetlb.
- At this time vm2 is created with 1G+2M memory. It finds that enough
memory is reserved (2G+2M), so it does not try to reserve more
memory.
- vm2 allocates some memory for its lowmem/highmem/ovmf.
- vm1 tries to allocate memory for its highmem/ovmf, the allocation
will fail. vm1 creation failed in this case.
Tracked-On: #3947
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Reviewed-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Currently, DM only access /sys/kernel/mm/hugepages/hugepages-2048kB/
entries according to its own huge page requirement. So it could have
following race issue:
DM1 DM2
read nr pages
read nr pages
write DM2 nr pages
write DM1 nr pages
Suppose we should write DM1 + DM2 nr page to kernel sysfs interface
to reserve enough huge page (DM1 + DM2). But actually only reserve
huge page requested by DM1. Which could trigger one VM can't boot.
We can easily hit this issue if we enable multiple UOS auto boot
because more than one VM are started at almost same time.
We add file lock to make sure huge page reserving in DM atomic.
Tracked-On: #3729
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
Acked-by: Wang Yu <yu1.wang@intel.com>
In order to support OVMF NV storage writeback, the High BIOS region in
the guest will behave as RAM and can be modified by OVMF itself. Give
the guest write permission to this page.
Tracked-On: #3413
Signed-off-by: Peter Fang <peter.fang@intel.com>
Acked-by: Yin Fengwei <fengwei.yin@intel.com>
Current hugetlbfs code has a limitation on file path length.
The path string comprises of mount path + vm name.
Something like /run/hugepage/acrn/huge_lv1/vm1.
To this UUID (32 bytes) is added and the total path length
should be less than 128.
This works fine but in cases where the VM name is large as
in case kata, this check fails. Kata passes a sandbox-id
as VM name and so path + 32 for UUID easily exceed 128 bytes.
“/run/hugepage/acrn/huge_lv1/
sandbox-6d455fa48788eae82dee42410fc3d38849c2a5196f930b3d6944805aed8d24c7"
To address this, increase the size of MAX_PATH_LEN from
128 to 256 bytes.
Tracked-On: #3379
Signed-off-by: Vijay Dhanraj <vijay.dhanraj@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
cleanup 'assert' usage to avoid possible software vulnerabilities.
Tracked-On: #3252
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Shuo A Liu <shuo.a.liu@intel.com>
If you run two acrn-dm processes at the same time,
hugetblfs will be mounted twice, which will cause a memory leak.
The specific solution is :different virtual machines mount hugetblfs
into different directories.
Tracked-On:#2854
Signed-off-by: bing.li <bingx.li@intel.com>
Reviewed-by: Minggui Cao<minggui.cao@intel.com>
Acked-by: Yin Fengwei<fengwei.yin@intel.com>
1G PCI hole is added just after 4G address which is used as the
PCI high MMIO address space. Guest high memory is mapped from 5G
address for both EPT and device model user space address. Guest
e820 table and API vm_map_gpa are updated accordingly.
Tracked-On: #2577
Signed-off-by: Jian Jun Chen <jian.jun.chen@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Yu Wang <yu1.wang@intel.com>
Also remove the '\n' from the hugetlb's file name.
Tracked-On: #2133
Signed-off-by: Shuo A Liu <shuo.a.liu@intel.com>
Reviewed-by: Yonghua Huang <yonghua.huang@intel.com>
Generic infrastructure for loading BIOS/ROM and providing EPT pages at
High BIOS region.
The size of High BIOS is rounded up to a multiple of 2MB.
v2 -> v3:
- refine mmap_hugetlbfs* to reduce code replication
v1 -> v2:
- make this code generic instead of OVMF-specific
Tracked-On: #1832
Signed-off-by: Peter Fang <peter.fang@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
check if there are enough free huge pages(1GB & 2MB now) for UOS,
if no, it will try to reserve more pages for UOS.
here are two examples
1. if system has free huge pages: 1 page of 1GB size, 0 page of 2MB.
one UOS need 2GB + 500MB memory, it will try to reserve one more 1GB
page and 250 2MB pages from system. If enough free system memory, it
can succeed.
2. if system has free huge pages: 4 pages of 1GB size, 0 page of 2MB.
one UOS need 2GB + 500MB, 1GB huge pages 4 > 2, it's enough, and 2 pages
left. It will try to reserve 250 2MB pages from system free memory,
if failed, it will try to release 1 of the 2 left 1GB pages. And then
try to reserve 250 2MB pages.
Signed-off-by: Minggui Cao <minggui.cao@intel.com>
Reviewed-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
adding API vm_map_memseg_vma() which using ioctl IC_SET_MEMSEG call
into VHM for futher mem(ept) mapping, based on user vma information.
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Xu, Anthony <anthony.xu@intel.com>
Type '-T' in DM cmdline to enable hugetlb memory allocation.
It enabled 2 level of huge page:
Level 1: size 2M, path: /run/hugepage/acrn/huge_lv1/guid
Level 2: size 1G, path: /run/hugepage/acrn/huge_lv2/guid
NOTE:
before running, please make sure system already have enough hugepages
reserved under:
/sys/kernel/mm/hugepages/hugepages-xxxxkB/nr_hugepages
Signed-off-by: Jason Chen CJ <jason.cj.chen@intel.com>
Acked-by: Xu, Anthony <anthony.xu@intel.com>
Ziheng Li