The targets "clean" and "distclean" are special as they do not need BOARD
or SCENARIO from users. This patch stops the guesswork of BOARD and
SCENARIO if any of those two targets are specified.
It is assumed that "clean" or "distclean" is not invoked with other targets
at the same time.
Tracked-On: #8259
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
In the current config.mk board and scenario XMLs are only copied to the
build directory when they do not exist. That prevents users from using XML
files they have edited, probably to fix previously reported validation
errors, for a rebuild unless the former build directory is totally removed.
This patch adds the user-given paths to XML files (if they exist) as
dependencies of the copied files in the build directory, so that users can
now provide new board and/or scenario XMLs to an existing build to
automatically trigger a complete rebuild.
Building without explicitly specifying BOARD and SCENARIO is still
supported if a build directory already exists. In that case the copied
board and scenario XMLs will not be modified.
Tracked-On: #8259
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
ACRN config tools generate source files, scripts and binaries based on
users' inputs in the configurations files, i.e., board and scenario
XMLs. Those generation activities all assume that users' inputs are
properly validated, so that all assumptions they have on such inputs are
hold.
Unfortunately, not all dependencies on validated user inputs are explicitly
stated in the Makefiles today. That will cause random error messages
(typically a Python stack trace) to be printed along with validation errors
when an invalid scenario XML is given, and such messages confuse users
about the root causes of the failure.
This patch decouples scenario validation from genconf.sh and make that step
as a separate target that depends on the board and scenario XMLs. One
timestamp file is generated only when the validation succeeds so that
targets requiring validated XMLs can refer that file in its dependency list
to make it explicit.
Dependencies of the following targets are also updated accordingly:
* $(HV_ALLOCATION_XML), which is the allocation XML including static
allocation results, now also depends on validated XMLs.
* $(HV_CONFIG_TIMESTAMP), which records when the config source files are
generated, now also depends on validated XMLs.
* $(SERIAL_CONF), which is the serial conf for the service VM, depends on
the allocation XML.
By the way, the missing dependency on HV_CONFIG_DIR for touching
HV_DIFFCONFIG_LIST is added to fix the "file not found" issue.
Tracked-On: #8259
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
In the top-level Makefile, the target "hypervisor" depends on "hvdefconfig"
because, at the time the latter is introduced, building without specifying
BOARD or SCENARIO is supported by using a pair of default board and
scenario XMLs.
This is no longer the case today, as BOARD and SCENARIO are now mandatory
command line options. As a result, that dependency is no longer necessary,
and this patch just removes that.
Tracked-On: #8259
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Phony targets are mostly for recipes that are expected to be invoked
directly from the command line as a target and will always be executed. As
a result, it is in most cases not appropriate for a real file target to to
depend on a phony one, as that means the file will always be regenerated.
In the Makefile today, however, dependencies on phony targets are common
and cause the hypervisor to be fully rebuilt regardless of whether an
existing build exists or not.
This patch cleans up the following phony targets which are not meant to be
targets from the command line.
- pre_build: This target has three outputs, namely the prebuild checker,
the ACPI tables for pre-launched VMs and the serial.conf. It is split
into three targets, one for each output.
- headers: This target is an alias of dynamically-generated header
files. It is replaced with a variable so that targets depending on
"header" now depends on the actual header files generated.
With this patch, make will only rebuild modified files and targets
depending on them directly or indirectly.
Tracked-On: #8259
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
The target "default" in hypervisor/Makefile is just an alias of the target
"all" in order to make "all" being the default goal. This patch replaces
that duplicate target and specifies the default goal by defining the
variable .DEFAULT_GOAL instead.
Tracked-On: #8259
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
1. In the full screen mode, a VM supports 4 virtual displays at most.
2. A vm supports 2 virtual windows at most.
3. The monitor ID cannot be duplicated in the full screen mode.
4. All the display elements are in DisplayConfiguration of VMType.xsd. It
cannot be set as required. Using assertions to check if the sub-elements
are set for any type of virtual display accordingly.
- check if a display has been added and a display type is set.
- check if monitor ID is set for full screen virtual display.
- check if resolution and offsets are set for window virtual display.
Tracked-On: #7970
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
add virtio gpu widget for the new design.
Tracked-On: #7970
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
If display type is "Windows", the generated launch script will follow
the below rule.
"virtio-gpu,geometry=<width>x<height>+<x_off>+<y_off>,geometry=<width>x<height>+<x_off>+<y_off>"
If display type is "Full screen", the generated launch script look like
this. For example:
"virtio-gpu,geometry=fullscreen:0,geometry=fullscreen:1"
Tracked-On: #7970
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
this patch refines virtio gpu device in the schema for new design.
Tracked-On: #7970
Signed-off-by: Kunhui-Li <kunhuix.li@intel.com>
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Now ACRN would traps MSI-X Table Structure access and does MSI-X interrupt
remapping for pass-thru PCIe devices. ACRN does this trap by unmmapping the
address ranges where the MSI-X Table Structure locates in granularity of 4K
pages. So there may have other registers (non-MSI-X structures) in these
trapped pages
However, the guest may access these registers (non-MSI-X structures) in these
trapped pages, which needs to be forwarded to the physical device. This patch
forwards the access to real hardware for pass-thru PCIe devices.
Tracked-On: #8255
Signed-off-by: Fei Li <fei1.li@intel.com>
When guest traps and wants to access a mmio region, the ACRN hypervisor
doesn't know the mmio size the guest wants to access until the trap
happens. In this case, ACRN should switch the mmio size and then call
mmio_read8/16/32/64 or mmio_write8/16/32/64 in each trap place.
This patch wrap the mmio read/write with a parameter to assign the mmio
size.
Tracked-On: #8255
Signed-off-by: Fei Li <fei1.li@intel.com>
Using e.g.
debuild -eACRN_BOARDLIST= -eACRN_SCENARIOLIST= -eCONFIGDIRS=<custom config path> -- binary
builds all board/scenario combinations provided in <custom config path>.
Tracked-On: #8246
Signed-off-by: Helmut Buchsbaum <helmut.buchsbaum@opensource.tttech-industrial.com>
To be able to set ACRN_BOARDLIST and ACRN_SCENARIOLIST via environment
variable when using debuild, both variables must be overridable.
Tracked-On: #8246
Signed-off-by: Helmut Buchsbaum <helmut.buchsbaum@opensource.tttech-industrial.com>
The debian build rule of calculating method for post launch vm ids
when generating launch scripts should not be reading //vm/@id in
scenario xmls directly but reading //vm/@id in scenario xml and
then plus vm id for service vm.
Since the objective here is to generate the launch scripts for all
VMs, change the debian rule to invoking the launch_cfg_gen.py script
without parameter user_vmid when there are post launch vms to achieve
the objective.
Tracked-On: #8245
Signed-off-by: szhen11 <shuang.zheng@intel.com>
Signed-off-by: Helmut Buchsbaum <helmut.buchsbaum@opensource.tttech-industrial.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
In markdown a single backtick around a term says to format it as
fixed-width text, e.g., `fixed-width text`. The rst language uses
double back-ticks, e.g., ``fixed-width text``.
Fix misuses of single backtick in our documentation.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Update known-issues processing and tweak conf.py and requirements.txt
(for PyPI package versions) to handle a broader version of
doc-generation tools (sphinx, breathe, docutils, etc.). This should
let us move to Ubuntu 22.04 while maintaining doc-build compatibility
with older tool versions available with Ubuntu 20.04 (doxygen in particular).
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Add bdf info of pio serial port to config.h.
Tracked-On: #8235
Signed-off-by: Yuanyuan Zhao <yuanyuan.zhao@linux.intel.com>
Reviewed-by: Junjie Mao junjie.mao@intel.com
The current code uses a predefined sworld memory array to reserve memory
for trusty VMs, and assume all post launched VMs are trusty VM which is
not correct.
This patch statically reserved memory just for trusty VMs and save 16M
memory for every non trusty VM.
Tracked-On: #6690
Signed-off-by: Chenli Wei <chenli.wei@intel.com>
Acked-by: Eddie Dong <eddie.dong@Intel.com>
The current code use VM number to calculate HV_RAM_SIZE, this is not
match the HV logic.
This patch use the max number of trusty VMs to calculate the size of
sworld memory and assume 4M ram / VM to calculate the final ACRN ram
size.
Tracked-On: #6690
Signed-off-by: Chenli Wei <chenli.wei@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
These changes are compatible with both the Ubuntu 20.04 and 22.04
documentation build processes.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
We have real fix in PR#8222, thus remove the workround in document.
delete the command: sudo pip3 install tqdm
Signed-off-by: zhangrouyu <rouyu.zhang@intel.com>
Tracked-On:8155
Evaluating an XPATH on a tree results an empty list (rather than None) when
that tree does not contain any matching node. This patch fixes a branch
condition that does not check the XPATH evaluation result properly.
Tracked-On: #8168
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
While PCIe specification defines only type 0 and type 1 configuration space
headers, there can be cases where a PCI function has a different header
type. As an example, that device itself is under development or is a
special emulated device.
This patch makes the board inspector gracefully skips those PCIe functions
and continue scanning the rest in such cases, as the only impact of the
anomaly is the prevention of ACRN from passing through that PCIe function
to any VM. It is an overkill to crash the board inspector.
Tracked-On: #6689
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
Today users are able to tweak whether the hypervisor includes support to
software SRAM (SSRAM). This, however, gives rise to potential functional
incorrectness when the hypervisor is not built with such support but a
service VM attempts to assign SSRAM to a post-launched VM (which is
possible as the service VM can still see the SSRAM-related ACPI tables). In
such cases the SSRAM assigned to a post-launched VM is not properly
initialized and thus not locked in cache.
As makes little sense for a user to configure the SSRAM support in the
hypervisor in a different way as the presence of SSRAM on hardware, this
patch removes the "SSRAM support" option from the configurator. The config
tools will now automatically enable the SSRAM support if the hardware
supports the feature and disable that otherwise.
Tracked-On: #8231
Signed-off-by: Junjie Mao <junjie.mao@intel.com>
This method gets connected displays andis add them as child nodes to
a corresponding graphics card.
Tracked-On: #7970
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Add 2 helplers:
1. get_realpath: this method returns the realpath of paramenter
if it's a valid path string
2. get_bdf_from_realpath: this method returns the bus, device, function
number if the parameter is a path to /sys/devices
Tracked-On: #7970
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
The design of ACRN CPU performance management is to let hardware
do the autonomous frequency selection(or set to a fixed value),
and remove guest's ability to control CPU frequency.
This patch is to implement the CPU frequency initializer, which will
setup CPU frequency base on the performance policy type.
Two performance policy types are provided for user to choose from:
- 'Performance': CPU runs at its CPU runs at its maximum frequency.
Enable hardware autonomous frequency selection if HWP is presented.
- 'Nominal': CPU runs at its guaranteed frequency.
The policy type is passed to hypervisor through boot parameter, as
either 'cpu_perf_policy=Nominal' or 'cpu_perf_policy=Performance'.
The default type is 'Performance'.
Both HWP and ACPI p-state are supported. HWP is the first choice, for
it provides hardware autonomous frequency selection, while keeps
frequency transaction time low.
Two functions are added to the hypervisor to call:
- init_frequency_policy(): called by BSP at start up time. It processes
the boot parameters, and enables HWP if it is presented.
- apply_frequency_policy(): called after init_frequency_policy().
It applies initial CPU frequency policy setting for each core. It
uses a set of frequency limits data struct to quickly decide what the
highest/nominal frequency is. The frequency limits are generated by
config-tools.
The hypervisor will not be governing CPU frequency after initial policy
is applied.
Cores running RTVMs are fixed to nominal/guaranteed frequency, to get
more certainty in latency. This is done by setting the core's frequency
limits to highest=lowest=nominal in config-tools.
Tracked-On: #8168
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
This patch is to generates frequency limits for each CPU, as a set of
data structure in hypervisor .c code.
With the frequency limits data, the hypervisor performance manager does
not have to deal with the CPU/board info. It just choose the
highest/lowest/guaranteed performance level and performance/nominal
p-state, and use them to construct HWP_REQUEST/PERF_CTL reg value.
How are frequency limits decided:
- For CPUs in standard VMs, frequency limits are just decided by
CPU/board info.
- For CPUs assigned to RTVMs, we want certainty in latency, so just
set its frequency to nominal/guaranteed by letting highest=lowest.
- In some cases, CPUs are sharing frequency on hardware level
(e.g. ADL e-cores in group of 4). This is described as _PSD in ACPI
spec, or 'frequency domain' in Linux cpufreq driver. Thoese CPUs'
frequency are linked together. If one of them are running RTVM,
all other CPUs in the domain should be set to the same frequency.
Tracked-On: #8168
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
This patch adds CPU frequency info extraction for board_inspector.
It is supposed to be used by ACRN CPU performance management.
Including those:
- Capabilities for HWP base regs, and turbo boost, by reading cpuids.
- Reporting all CPUID bits in LEAF 06H.
- Max none turbo ratio and max turbo ratio, by reading MSRs.
- HWP capabilities, by reading IA32_HWP_CAPABILITIES. Reading this
register requires HWP enabled in IA32_PM_ENABLE. (SDM Vol3 14.4.2:
Additional MSRs associated with HWP may only be accessed after HWP
is enabled)
- ACPI _PSD info, by reading sys nodes of Linux acpi-pstate driver.
This table describes frequency domains in which CPUs shares the same
frequency.
Tracked-On: #8168
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
This patch is to generate an ACRN CPU performance policy type boot
parameter.
The generated parameter is either 'cpu_perf_policy=Performance’ or
‘cpu_perf_policy=Nominal’, according to the 'CPU performance policy type'
config item in configurator.
It will then be packed into acrn-hypervisor deb file, and will be
automatically added to grub cfg file through installation.
Tracked-On: #8168
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Add 'CPU performance policy type' option to configurator. User can choose
from 'Performance' or 'Nominal' as the CPU performance policy for ACRN to
apply.
Tracked-On: #8168
Signed-off-by: Wu Zhou <wu.zhou@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
The cpu_affinity is null when creating a new scenario. Do not update the
pcpu properties if the cpu_affinity is null.
Tracked-On: #8145
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Prevent allocator to allocate PCI bus mmio windows to other devices.
Tracked-On: #8191
Signed-off-by: Yang,Yu-chu <yu-chu.yang@intel.com>
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Added python3-tqdm depend in gen_acrn_deb.py
Tracked-On: #8155
Reviewed-by: Junjie Mao <junjie.mao@intel.com>
Signed-off-by: Ziheng Li <ziheng.li@intel.com>
Some member of CACHE_REGION have no documentation element, this cause
some issue when we generate documentation for user.
This patch add some documentation to fix the above issue.
Tracked-On: #6690
Signed-off-by: Chenli Wei <chenli.wei@intel.com>
Junjie Mao