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

From: szhen11 <shuang.zheng@...> $ debian/debian_build.sh -h Usage: debian/debian_build.sh [--board_list ACRN_BOARDLIST] [--scenario_list ACRN_SCENARIOLIST] [--config_path CONFIGDIRS] [--release n|y]

After comfirmation from aspects of QEMU/KVM/ANDROID, it is still recommended to preserve the patches--hiding PMU in the acrn release mode, based on below reasons: 1) PMU passthrough to VM makes other

$ debian/debian_build.sh -h Usage: debian/debian_build.sh [--board_list ACRN_BOARDLIST] [--scenario_list ACRN_SCENARIOLIST] [--config_path CONFIGDIRS] [--release n|y] [acrn | board_inspector | clean]

From: yuchuyang <yu-chu.yang@...> Any required elements in VMtypes.xsd will be present in first time generated scenario XML. However, not every vm needs gpu configuraition. Add minOccurs="0" to all Vi

$ debian/debian_build.sh -h Usage: debian/debian_build.sh [--board_list ACRN_BOARDLIST] [--scenario_list ACRN_SCENARIOLIST] [--config_path CONFIGDIRS] [--release n|y] [acrn | board_inspector | clean]

$ debian/debian_build.sh -h Usage: debian/debian_build.sh [--board_list ACRN_BOARDLIST] [--scenario_list ACRN_SCENARIOLIST] [--config_path CONFIGDIRS] [--release 0|1] [acrn | board_inspector | clean]

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. v1->v2 1. give explicit xpath(s) 2. combine 2 "f

The current code would write 'BAR address & size_maks' into PCIe virtual BAR before updating the BAR's base address. However, if the size of a PCIe device's BAR is larger than 4G, the size_mask of low

Hi, I could not find partition mode boot guide in latest web doc. If switching to 2.0 verison in webdoc page, then could find gettting started guide for partition mode. From these below description, i

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 lo

v2: revise the commit message 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 wher

When vCPU is idle HLT or MWAIT can be used to enter C-state. For VMs share pCPUs, HLT will be traped and reschedule to other vCPU. MWAIT passthrough will enter C-state until an event cause exit. In AC

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

Use mmio_read/write directly. Signed-off-by: Fei Li <fei1.li@...> --- hypervisor/hw/pci.c | 29 +++-------------------------- 1 file changed, 3 insertions(+), 26 deletions(-) diff --git a/hypervisor/hw

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

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

When launch a VM own pcpus, offline Service VM vcpus which use the same pcpu by launch script. v1->v2 add warning to offline cpu 0 Signed-off-by: Yuanyuan Zhao <yuanyuan.zhao@...> Reviewed-by: Junjie

Add "exclusively owns physical CPUs" checkbox to pre-launched VMs and post-launched VMs. RTVM will not display this checkbox. If this checkbox is set, the VM will use all the pCPUs assigned to it alon

Hello: Does current acrn project support booting SOS with ovmf firmware? It seems SOS is booted with grub directly. In some case, i just want to boot to an ovmf UEFI BIOS's shell environment with acrn