In addition to a single OVMF image (OVMF.fd), split images
(OVMF_CODE.fd, OVMF_VARS.fd) can be used to facilitate VM management.
From the OVMF Whitepaper:
The variable store and the firmware executable are also available in
the build output as separate files entitled: "OVMF_VARS.fd" and
"OVMF_CODE.fd". This enables central management and updates of the
firmware executable, while each virtual machine can retain its own
variable store.
An example to launch acrn-dm with the split images:
--ovmf code=/usr/share/acrn/bios/OVMF_CODE.fd, \
vars=/usr/share/acrn/bios/OVMF_VARS.fd
v1 -> v2:
- use memory-mapped file I/O for writeback
- use fcntl to lock OVMF image files
Tracked-On: #5487
Signed-off-by: Peter Fang <peter.fang@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
Unifies the logs to pr_* interfaces instead of printf for better log management.
Tracked-On: #5267
Signed-off-by: Sun Peng <peng.p.sun@intel.com>
Reviewed-by: Chi Mingqiang <mingqiang.chi@intel.com>
Acked-by: Wang, Yu1 <yu1.wang@intel.com>
use acrn-dm logger function instread of fprintf,
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>
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>
To support modification of OVMF NV storage, add an option "w" for
--ovmf to write the changed OVMF NV data section back to the OVMF image
from guest memory before deinit operations. This will enable persistent
EFI variables. Only option "w" is supported, dm will exit if passing
invalid option. It expects OVMF NV storage writeback with option "w"
when power off or reboot the UOS, poweroff, cold and warm reboot in EFI
shell and when dm recieves SIGINT and SIGHUP.
Tracked-On: #3413
Signed-off-by: Yang, Yu-chu <yu-chu.yang@intel.com>
Reviewed-by：Eddie Dong <eddie.dong@intel.com>
Acked-by: Yin Fengwei <fengwei.yin@intel.com>
cleanup 'assert' to avoid possible vulnerabilities.
Tracked-On: #3252
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Shuo A Liu <shuo.a.liu@intel.com>
OVMF requires a more descriptive mechanism than RTC CMOS to retrieve
ACRN's memory layout, so we now pass the E820 map to it, starting at
0xEF000 (ROM area).
ACRN currently uses [4GB, 5GB) as its 64-bit PCI host aperture. This is
inconsistent with OVMF's assumption of its platform's memory layout,
because it derives the size of high memory from RTC CMOS, which is
incapable of describing the 64-bit PCI hole.
By default, OVMF uses RTC CMOS 0x5b/0x5c/0x5d to determine the size of
high memory. This value only tells OVMF how much memory is above 4GB,
but not the platform's memory layout above 4GB.
Using RTC CMOS works for QEMU, because QEMU places its 64-bit PCI host
aperture above its highmem. Therefore, OVMF can always assume highmem is
located at [4GB, 4GB + highmem), which is not where ACRN's highmem is
located. For example, if we have 1GB of usable memory above 4GB, ACRN
will place it at [5GB, 6GB).
This change allows OVMF to correctly identify the guest's memory layout.
It will consider any reserved region above 4GB as 64-bit PCI host
aperture.
MP table, SMBIOS and ACPI tables are all located above 0xF0000 so it is
guaranteed that there is no overlap. There can only be a maximum of 128
E820 entries.
v1 -> v2:
- provide more explanation to this commit
- add signature before E820 map for OVMF backward compatibility
Tracked-On: #2792
Signed-off-by: Peter Fang <peter.fang@intel.com>
Reviewed-by: Eddie Dong <eddie.dong@intel.com>
Acked-by: Yin Fengwei <fengwei.yin@intel.com>
Use '--ovmf <OVMF image location>' when launching acrn-dm.
Tracked-On: #1832
Signed-off-by: Peter Fang <peter.fang@intel.com>
Acked-by: Anthony Xu <anthony.xu@intel.com>
Shuo A Liu