Remove hybrid.xml, hybrid_rt.xml, logical_partition.xml and
industry_launch_2uos.xml files because validation team found
that these scenario files not working. And these documents will be
resubmitted after them are verified successfully.
Tracked-On: #6244
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
1. Update python script name that is executed to generate board xml file
from run.py to cli.py in README file.
2. Update the OS requirement under native Linux in
misc/config_tools/board_inspector/README file.
Tracked-On: #6134
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
This reverts commit 24af7f8f9d which leaves
MAX_MSIX_TABLE_NUM item as empty for most of platforms except ehl-crb-b and
expect config tool to calculate a correct MAX_MSIX_TABLE_NUM for hypervisor
use. Unfortunately current config tool just calculate maximum native MSIX
number without evaluating the maximum MSI vectors that ACRN needed for vMSIX
emulation, thus introduce big risk on the device vMSIX table initialization.
If customer has special device that need larger MAX_MSIX_TABLE_NUM to enable
ACRN, he can input the number in his own scenario file.
Tracked-On: #6186
Signed-off-by: Victor Sun <victor.sun@intel.com>
1. Update the value of the tag MAX_MSIX_TABLE_NUM from 64 to empty
for all scenario xml except ehl-crb-b board.
2. Update the value of the tag MAX_MSIX_TABLE_NUM to 96 for the
scenario xml on the ehl-crb-b board.
Tracked-On: #6186
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Update the value of the tag MAX_PT_IRQ_ENTRIES from 64 to 128
in TGL-RVP scenario xml.
Tracked-On: #6185
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
A vmsix supported passthrough device expects the first unused bar region
for vmsix. Pop the first unused_bar_index in gpa.py instead.
Reference code: init_vmsix_on_msi of hypervisor\dm\vpci\vmsix_on_msi.c
Tracked-On: #6192
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Refine get_pt_intx_table. The method parse the <pt_inx> of scenario and
append the pair of phys_gsi and virt_gsi if there is any.
Refine check_pt_intx. Add a condition that the method returns if the
phys_gsi and virt_gsi are empty dictionary.
Tracked-On: #6178
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Add flag "allow_trigger_s5" to launch script xmls. If this flag sets to
'y' and the poweroff_channel sets to "vuart1(pty)" or "vuart1(tty)", the
"allow_trigger_s5" will appends to the end of "--pm_notify_channel
uart".
Tracked-On: #6138
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
This reverts commit 033f458d85.
Remove the code change that save the board xml into misc/config_tools/data/[board]/ when loading a new board from config tool UI.
Tracked-On: #6104
Signed-off-by: Kunhui Li <kunhuix.li@intel.com>
Make up qemu.xml to compromise the static allocators which use the
new xpath based on board inspector.
Tracked-On: #6102
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Update the severity from "warning" to "error" for hybrid cores check.
Tracked-On: #5918
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Kunhui Li <kunhuix.li@intel.com>
Modify the initial value of PT_SLOT variable and
update the get slot logic that all device call the virtual_dev_slot function to get slot number directly.
Copy the launch_uos_id1.sh to launch_win.sh.
Tracked-On: #6072
Signed-off-by: Kunhui Li <kunhuix.li@intel.com>
For illegal characters, replace original characters with escaped characters in board.xml.
Tracked-On: #6113
Signed-off-by: Kunhui Li <kunhuix.li@intel.com>
save the board xml into misc/config_tools/data/[board]/ when
loading a new board from config tool UI.
Tracked-On: #6104
Signed-off-by: Kunhui Li <kunhuix.li@intel.com>
This patch sets the MemoryOverwriteRequestControl (MORCtrl for short)
EFI variable before jumping to hypervisor.
Setting variable MemoryOverwriteRequestControlLock (MORCtrlLock for
short) can also be enabled by manually adding -DMORCTRL_LOCK_ENABLED to
CFLAGS.
Setting MORCtrl indicates to the platform firmware that memory be
cleared upon system reset. Setting MORCtrlLock for the first time will
render both MORCtrl and MORCtrlLock to read-only, until next reset.
Tracked-On: #6097
Signed-off-by: Yifan Liu <yifan1.liu@intel.com>
ACRN EFI application based on the legacy efi-stub code provides booting method
of HV on UEFI-BIOS without using the GRUB Bootloader. It is supposed to be used
for secure booting on certain platform. By means of that users can boot HV,
Service VM kernel, pre-launched VM kernel and its ACPI table binary packed in
the Slim Bootloader container boot image file format. ACRN EFI application has
additional dependencies to compile which are not listed in the existing ACRN GSG
doc. Since this is an optional feature but not all users need, it does not get
compiled by default to avoid causing any confusion for existing users. README
for how to use the feature will come later in a separated commit.
Tracked-On: #6078
Signed-off-by: Toshiki Nishioka <toshiki.nishioka@intel.com>
Signed-off-by: Yifan Liu <yifan1.liu@intel.com>
Co-developed-by: Yifan Liu <yifan1.liu@intel.com>
commit 873ed75 ("misc: sanity check VM config for nested virtualization")
requires that the guest_flag tag can't be empty, or it will fail to build.
This patch changes adl instances of "<guest_flag></guest_flag>" to
"<guest_flag>0</guest_flag>".
Tracked-On: #5923
Signed-off-by: Jiang, Yanting <yanting.jiang@intel.com>
Retrieve physical APIC IDs from board xml file and use them to fill in the ACPI MADT table
for pre-Launched VMs.
Note that the config-tool will throw an error if the processors/die/core/thread tags are absent.
User needs to run board_inspector.py to regenerate the board xml file when this commit is merged,
if the processors/die/core/thread tags are missing in the board xml file.
Tracked-On: #6020
Signed-off-by: dongshen <dongsheng.x.zhang@intel.com>
Configure PTM in post-launched VM using <PTM> element. If the //vm/PTM
sets to 'y', pci_dev.c.xsl appends the virtual root port to
corresponding struct acrn_vm_pci_dev_config of that VM. Currently it
supports only post-launched VMs.
Configure enable_ptm for dm argument. If a uos/enable_ptm with uos id
= 'vm_id 'sets to 'y' and the vm/PTM with the same vm_id sets to 'y',
append an "enable_ptm" flag to the end of passthrough ethernet devices.
Currently there is only ethernet card can support the "enable_ptm"flag.
For the schema validation, the <PTM> can only be ['y', 'n'].
For the launched script validation, the <enable_ptm> can only be ['y',
'n']. If the <enable_ptm> sets to 'y' but the corresponding <PTM> sets
to 'n', the launch script will fail to generate.
Tracked-On: #6054
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Add an xslt file "board_info.h.xsl". This file is used to
generate board_info.h which is used by hypervisor.
Tracked-On: #6024
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Add an xslt file "pci_dev.c.xsl". This file is used to
generate pci_dev.c which is used by hypervisor.
Tracked-On: #6024
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
acrn:get-vbdf: get the virtual bdf from allocation.xml based on vmid and device name
acrn:get-pbdf: get physical bdf from <pci_dev>
acrn:ptdev-name-suffix: fix the name to look up allocation.xml
acrn:get-hidden-device-num: get the number of hidden devices based on
board name
acrn:is-vmsix-supported-device: check if a device is a vmsix supported
device based on the vendor and identifier
Tracked-On: #6024
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Assign bdf to pci emulated and passthrough devices.
For pre-launched VM, assigns unique bdf to passthrough devices, inter-vm
shared memory, pci vuart(console and communication vuarts).
For SOS vm, assigns unique bdf to inter-vm shared memory and pci
vuart(console and communication vuarts).
The bdf follows the rules below:
- the bdf 00:00.0 is reserved for pci hostbridge
- the assigned bdf range: bus is 0x00, dev is in range [0x1, 0x20)
and the fuc is 0x00
- the bdf must be unique, which means any vm's emulated devices cannot
share the same bdf with existing devices
- some devices's bdf is hardcoded, modify its bdf would leads the
device cannot be dicoverd by os. A HARDCODED_BDF_LIST in bdf.py documents
them
- the passthrough devices' bdf can be reused in SOS vm
Tracked-On: #6024
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Add methods allocates the mmio bar base to console vuart,
communication vuarts, inter-vm shared memory and passthrough pci
devices.
For SOS:
- get low mem by parsing board xml.
- get high mem by parsing board xml, if the high mem is not enabled,
the high mem start address would be ~0UL and the end address is 0UL
- get the occupied mmio windows by parsing board.xml
- for each console vuart, communication vuart and inter-vm shared memory
devices, assign unused mmio windows to them
- all the assigned mmio windows must be unique and should not overlay
with any devices' mmio window
- the passthrough devices mmio windows can be reused in SOS vm
- each allocated mmio start address must be 4k alignment if the length
of bar is smaller than 4k
- each allocated mmio start address must be aligned with the bar length
if its length is greater than 4k
- the 32bits bar will fall in low mem range only
- 64bits bar will look for free mmio in low mem rage first, if the high
mem is enabled, the 64bits bar will look for free mmio in high mem
range if there is not enough space in low mem range
- allocator raises an error if there is not enough mmio space
For pre-launched VM:
- the high mem range is [256G, 512G)
- the low mem range is [2G, 3.5G)
- there is no used mmio window initially
- for each console vuart, communication vuart, inter-vm shared memory
devices and passthrough devices, assign unused mmio windows to them
- all the assigned mmio windows must be unique and should not overlay
with any devices' mmio window
- the 32bits bar will fall in low mem range only
- 64bits bar will look for free mmio in low mem rage first and then
look for free mmio in high mem range if there is not enough space in
low mem range
- each allocated mmio start address must be 4k alignment if the length
of bar is smaller than 4k
- each allocated mmio start address must be aligned with the bar length
if its lenght is greater than 4k
- allocator raises an error if there is not enough mmio space
Tracked-On: #6024
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Add a common method "get_shmem_regions":
This method get <IVSHMEM_REGION> and extracts the region size, region
position in xml and and vm ids which share this regions. Returns a
dictionary:
{'vm_id':{'region_name':{'id': region position,'size': region size,}}}
Add vm type checking methods:
is_pre_launched_vm, is_post_launched_vm and is_sos_vm.
Tracked-On: #6024
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
If there is hugepage support from board xml, config tool will
add hugepagesz=1G hugepages=[size] into sos kernel cmdline,
the size is calculated by memory size in G minusing 3.
The reason for reducing 3 is that it is reserved for SOS VM use.
Tracked-On: #5815
Signed-off-by: Kunhui Li <kunhuix.li@intel.com>
Reviewed-By: Junjie Mao <junjie.mao@intel.com>
* Split linux and windows build of lifemngr to be able to build
them independently.
* Install life_mngr.service
* Avoid the following Makefile error output by explicitly checking
Windows cross compiler availability:
make[4]: x86_64-w64-mingw32-gcc: Command not found
make[4]: [Makefile:47: all-win] Error 127 (ignored)
Tracked-On: #5660
Signed-off-by: Helmut Buchsbaum <helmut.buchsbaum@opensource.tttech-industrial.com>
Use BUILD_VERSION an BUILD_TAG variable also for hypervisor,
acrnprobe and crashlog. This eases build from an archive without
git available.
Tracked-On: #6035
Signed-off-by: Helmut Buchsbaum <helmut.buchsbaum@opensource.tttech-industrial.com>
Make builds reproducible by honoring SOURCE_DATE_EPOCH and USER
environment variables in the respective Makefiles. Just follow the
recommendations at https://reproducible-builds.org/
Build tools (e.g. Debian packaging, Yocto) use this to ensure reproducibility
of packages.
Tracked-On: #6035
Signed-off-by: Helmut Buchsbaum <helmut.buchsbaum@opensource.tttech-industrial.com>
Unify two functions definitions/declarifications:
Update the parameters from char array to char pointer.
to fix the build issue:
probeutils.c:61:29: error: argument 1 of type 'char *' declared
as a pointer [-Werror=array-parameter=]
Initialize local variable "c" to fix build issue:
core/mevent.c:122:21: error: 'c' may be used uninitialized
[-Werror=maybe-uninitialized]
Tracked-On: #5993
Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
This patch applies the latest board inspector on ehl-crb-b and tgl-rvp to
generate additional information to the board XMLs.
Tracked-On: #5922
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch adds support to parse RTCT v2 using the refined board XML
schema. The major changes include:
- Add the RTCT v2 parser in the acpiparser module. The version of an RTCT
is detected automatically to choose the right parser.
- Extract software SRAM capabilities of caches into the board XML.
- Move the logic that determines the software SRAM base address for the
pre-launched VM to the static allocator of GPAs.
- Generate software SRAM related macros into misc_cfg.h when necessary.
Tracked-On: #6020
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
commit 873ed752d ("misc: sanity check VM config for nested virtualization")
requires that the guest_flag tag can't be empty, or it will fail to build.
This patch changes all instances of "<guest_flag></guest_flag>"
to "<guest_flag>0</guest_flag>".
Tracked-On: #5923
Signed-off-by: Zide Chen <zide.chen@intel.com>
'psram' and 'PSRAM' are legacy names and replaced
with 'ssram' and 'SSRAM' respectively.
Tracked-On: #6012
Signed-off-by: Yonghua Huang <yonghua.huang@intel.com>
Reviewed-by: Shuang Zheng <shuang.zheng@intel.com>
This patch introduces the XML schema `datachecks.xsd` which is the central
place to specify and check assumptions on board characteristics and
scenario settings. Each assumption is expressed as an XSD assertion with
annotation of error severity (e.g. info, warning or error) and detailed
descriptions.
At compile time, the board and scenario XMLs are combined (by putting the
children of the root node together) can checked against the
schema. Assertion failures are categorized according to the defined
severity. Currently only errors will block compilation by outputing the
descriptions of the violated assertions.
The objective of this patch is the introduce the framework to document,
manage and check assumptions. A better way to present assumption violations
to end users (either on the command line or in the configuration editor) is
out of the scope of this series and will be considered in the future.
Tracked-On: #5922
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch extracts information on devices and put them under the
`/acrn-config/devices` node in the board XML.
The generated XML looks like the following:
<devices>
<bus type="system">
<acpi_object>\_SB_</acpi_object>
<bus id="PNP0A08" type="pci" address="0x0" description="...">
<vendor>0x8086</vendor>
<identifier>0x591f</identifier>
<subsystem_vendor>0x1028</subsystem_vendor>
<subsystem_identifier>0x07a1</subsystem_identifier>
<class>0x060000</class>
<acpi_object>\_SB_.PCI0</acpi_object>
<resource type="bus_number" min="0x0" max="0x3e" len="0x3f"/>
<resource type="io_port" min="0x0" max="0xcf7" len="0xcf8"/>
<resource type="io_port" min="0xcf8" max="0xcf8" len="0x8"/>
<resource type="io_port" min="0xd00" max="0xffff" len="0xf300"/>
<resource type="memory" min="0x10000" max="0x1ffff" len="0x0"/>
<resource type="memory" min="0xa0000" max="0xbffff" len="0x20000"/>
<resource type="memory" min="0xc0000" max="0xc3fff" len="0x4000"/>
<resource type="memory" min="0xc4000" max="0xc7fff" len="0x4000"/>
...
<capability id="vendor_specific"/>
<device address="0x1"> ... </device>
...
<bus>
<bus>
<device> ... <device>
<devices>
The hierarchy of devices are based on the hierarchy of device objects in
the ACPI namespace (which is established by interpreting the ACPI DSDT and
SSDT tables). Typically most device objects are under the predefined
`_SB_` (i.e. System Bus) object under which an object representing the PCI
root complex (`\_SB_.PCI0` in the example above) can be found. The PCI
devices attached to bus 0 are listed as children of the PCI root complex
node.
For each bus or device, the board inspector tries best to parse the
information from both ACPI device objects and PCI configuration space to
extract the following:
- the model (via `_HID` object and PCI vendor ID, device ID and class code),
- assigned resources (via `_CRS` object and PCI BARs),
- capabilities (via the PCI capability list)
v1 -> v2:
- Fix references to undeclared modules or variables.
- Make the ACPI extractor advanced and not enabled by default.
- Extract the secondary I/O and memory-mapped I/O addresses of bridges.
Tracked-On: #5922
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch extracts information on mapping of available RAM and put them
under the `/acrn-config/memory` node in the board XML. Each range of
available RAM is represented by its start (host physical) address, end
address and size (in byte).
The following is an example of the generated XML.
<memory>
<range start="0x0000000000000000" end="0x0000000000057fff" size="360448"/>
<range start="0x0000000000059000" end="0x000000000009dfff" size="282624"/>
<range start="0x0000000000100000" end="0x00000000c9ff9fff"
size="3387924480"/>
<range start="0x00000000c9ffc000" end="0x00000000d984afff"
size="260370432"/>
<range start="0x00000000dbdff000" end="0x00000000dbdfffff" size="4096"/>
<range start="0x0000000100000000" end="0x000000041dffffff"
size="13388218368"/>
</memory>
Tracked-On: #5922
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch extracts information on cache topology and capabilities and put
them under the `/acrn-config/caches` node in the board XML in the following
manner.
<caches>
<cache level="1" id="0x0" type="1">
<cache_size>32768</cache_size>
<line_size>64</line_size>
<ways>8</ways>
<sets>64</sets>
<partitions>1</partitions>
<self_initializing>1</self_initializing>
<fully_associative>0</fully_associative>
<write_back_invalidate>0</write_back_invalidate>
<cache_inclusiveness>0</cache_inclusiveness>
<complex_cache_indexing>0</complex_cache_indexing>
<processors>
<processor>0x0</processor>
<processor>0x1</processor>
</processors>
</cache>
<cache level="1" id="0x0" type="2"> ... </cache>
<cache level="1" id="0x1" type="1"> ... </cache>
<cache level="1" id="0x1" type="2"> ... </cache>
...
<cache level="2" id="0x0" type="3"> ... </cache>
<cache level="2" id="0x1" type="3"> ... </cache>
...
<cache level="3" id="0x0" type="3"> ... </cache>
</caches>
Each cache block is represented by a separate `cache` node identified by
its level, cache ID and type (as reported by CPUID). More information, such
as the size, characteristics and capabilities, are attached as children of
the node.
The current implementation fetches cache information solely from the CPUID
leaf 4H. In the future more cache-related information, such as those in the
ACPI RTCT tables, will be appended here.
Tracked-On: #5922
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This patch extracts information on CPU topology and capability and put them
under the `/acrn-config/processors` node in the board XML.
The added information can be divided into two categories.
1. The topology of CPUs like the following. Each thread (which is a leaf
node in the topology) contains its addresses (i.e. CPU ID, APIC ID,
x2APIC ID) and model identifiers (i.e. family, model, stepping IDs, core
types and native model ID).
<die id="0">
<core id="0x0">
<thread id="0x0">
<cpu_id>0</cpu_id>
<apic_id>0x0</apic_id>
<x2apic_id>0x0</x2apic_id>
<family_id>0x6</family_id>
<model_id>0x9e</model_id>
<stepping_id>0x9</stepping_id>
<core_type></core_type>
<native_model_id></native_model_id>
</thread>
<thread id="0x1"> ... </thread>
</core>
<core id="0x1">
<thread id="0x2"> ... </thread>
<thread id="0x3"> ... </thread>
</core>
<core id="0x2">
<thread id="0x4"> ... </thread>
<thread id="0x5"> ... </thread>
</core>
<core id="0x3">
<thread id="0x6"> ... </thread>
<thread id="0x7"> ... </thread>
</core>
</die>
2. The CPU models identified by the quadruple (family_id, model_id,
core_type, native_model_id). Each model is described by its brandstring
and capabilities, both of which are fetched from CPUID leaves.
<model description="Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz">
<family_id>0x6</family_id>
<model_id>0x9e</model_id>
<core_type></core_type>
<native_model_id></native_model_id>
<capability id="sse3"/>
<capability id="pclmulqdq"/>
<capability id="dtes64"/>
<capability id="monitor"/>
...
</model>
Tracked-On: #5922
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
