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

Hi Yoshinoya, For your first question, YES, ACRN shell is up before the service VM starts. It is, however, worth noting that ACRN shell is designed to inspect hardware & VM status and states for debug

From: "Yang,Yu-chu" <yu-chu.yang@...> Clean up vm_name of vuart and/or VM_NAME of IVSHMEM which is not defined in //vm/name while loading scenario XML. Signed-off-by: Yang,Yu-chu <yu-chu.yang@in

This is for the case of cache sharing among 2 VMs, right? I thought it is fine for cache partitioning cases. I remember the initial purpose to pass thru PMU to a guest is for IVI usage, where the Andr

The MSIX-x table registers are located in one of the PCIe BAR, and is intercept and emulated by ACRN. However, the bar may contain registers other than MSI-X table registers, which is trapped by ACRN

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 --- hype

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

This patch set is to disable PMU passthrough in release mode, since it may cause security concern through collecting sensitive data such as cache miss latency to carry on side channel analysis, thus d

Hi, Junjie: Based on webdoc, the acrn boot flow is: uefi ----> acrn.efi ----> acrn hypervisor ----> Service VM Kernel (Service OS) So, i have 2 questions: 1. ACRN Shell, where it is? uefi ----> acrn.e

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

+1!

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

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

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