Exclude "GUEST_FLAG_PMU_PASSTHROUGH" from DM_OWNED_GUEST_FLAG_MASK in case device model rewrite the value in release mode. Signed-off-by: hangliu1 <hang1.liu@...> Tracked-On:#6690 --- hypervisor/inclu

In release mode, "GUEST_FLAG_PMU_PASSTHROUGH" is not generated for specific VM. Signed-off-by: hangliu1 <hang1.liu@...> Tracked-On:#6690 --- misc/config_tools/static_allocators/guest_flags.py | 2 +- 1

The debian build rule for calculating method for post launch vm ids is changed from reading //vm/@id in scenario xmls directly to reading //vm/@id in scenario xml and then plus vm id for service vm. T

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

From: Kunhui-Li <kunhuix.li@...> 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 sc

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 re

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' inpu

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

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

Dependencies among targets in Makefiles today have the following issues: 1. Phony targets are used for intermediate files. That causes unnecessary rebuilds of almost all sources even no source file is

Hello: I have a question about cpu feature: IA32_XSS feature support is a must requirment, or optional. Where to config it on or off. Thanks

Hello: Does current acrn hypervisor still support booting from uefi shell directly? Such as: compiled acrn hypervisor as a efi binary. UEFI BIOS could launch it directly. Thanks

The serial fix pass-thru pcie device may access MSI-X BAR besides MSI-X Table Structure. Fei Li (3): hv:io: wrap mmio read/write hv: pci: use mmio_read/write directly hv: vpci: fix pass-thru pcie devi

From: Kunhui-Li <kunhuix.li@...> add virtio gpu widget for the new design. v5->v6 No changes. Tracked-On: #7970 Signed-off-by: Kunhui-Li <kunhuix.li@...> Signed-off-by: Yang,Yu-chu <yu-chu.yang@...> R

From: Kunhui-Li <kunhuix.li@...> this patch updates the upgrader.py script for virtio gpu. v5->v6 No change. Tracked-On: #7970 Signed-off-by: Kunhui-Li <kunhuix.li@...> Signed-off-by: Yang,Yu-chu <yu-

From: Kunhui-Li <kunhuix.li@...> 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>+<

From: Kunhui-Li <kunhuix.li@...> this patch refines virtio gpu device in the schema for new design. v5->v6 No change. Tracked-On: #7970 Signed-off-by: Kunhui-Li <kunhuix.li@...> Signed-off-by: Yang,Yu

From: Kunhui-Li <kunhuix.li@...> 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 sc

From: Kunhui-Li <kunhuix.li@...> add virtio gpu widget for the new design. v4->v5 No changes. There is no default value of virtio GPU devices. Using assertion in virtio_devices.xsd to check the settin

From: Kunhui-Li <kunhuix.li@...> this patch refines virtio gpu device in the schema for new design. v4->v5 1. make the elements of DisplayConfiguration minOccurs="0" 2. there is no default values of v