Hi Jianjie

If you still have sos reboot issue after following setting, please help to raise git issue @https://github.com/projectacrn/acrn-hypervisor/issues/

sudo systemctl set-default multi-user.target  

BR.

Fuzhong

Hi Terry,

Thank you for your reply.

My system is stable and “dmesg |grep ACRN” also shows the correct message.

After I launch the guest Ubuntu in the acrn kernel, the acrn kernel (service VM) is directly reboot, and nothing happens (Here means the system just restart, and go the service VM again, but guest VM did not launch)

I follow the instruction in https://projectacrn.github.io/latest/getting-started/getting-started.html to install the ACRN hypervisor,

and follow the tutorial in https://projectacrn.github.io/latest/getting-started/roscube/roscube-gsg.html for installing the User VM, but without installing ROS environment.

Therefore the launch_ubuntu.sh is almost the same as in the  https://raw.githubusercontent.com/Adlink-ROS/ROScube_ACRN_guide/v2.1/scripts/launch_ubuntu_uos.sh

By the way,  I try the ACRN hypervisor in a dell pc with x86 cpu, I am not sure if this the NUC platform or not? Or Can we use an PC for deploying the ACRN hypervisor?

Thank you very much again for your help, and support.

Cheers,

Jianjie Lin

Hi Jianjie, welcome to ACRN world : )
For your reboot issue, first, you already successfully boot ACRN and Ubuntu SOS right, you can check dmesg as below. If you don't launch Guest VM, the system is stable right.

$ dmesg | grep ACRN

[    0.000000] Hypervisor detected: ACRN

[    0.862942] ACRN HVLog: acrn_hvlog_init

Then, you just run launch_ubuntu.sh to launch guest VM, could you login Ubuntu for first time or just reboot and never succeed ? BTW, which platform are you trying on, a NUC platform, e.g., NUC11 ?

There are two steps for next debug: 1. could you enclosed your 'launch_ubuntu.sh', we can check if anything missed. 2. enable serial port to get HV log for next analysis: https://projectacrn.github.io/latest/tutorials/using_serial_port.html

Best & Regards
Terry

Hi Jianjie

Which platform are you using?

You are using GVT-d for UOS, right?

Please have a try with following command in SOS and reboot:

sudo systemctl set-default multi-user.target  

BR.

Fuzhong

All the ACRN release documentation are archived and available online.  If you click on the version selector icon (where it says v:latest under the search box in the left navigation pane, you can then click on any of the listed versions (such as 1.0) and get to the v1.0 ACRN documentation.  (You can also manually enter the URL for the version of ACRN documentation, for example for v1.0: https://projectacrn.github.io/1.0/  or for v1.5: https://projectacrn.github.io/1.5/   

I do see this Celadon document in the v1.5 archive that might be relevant, but maybe Terry has a specific document in mind: Using Celadon as the User OS — Project ACRN™ v 1.6-unstable documentation

-- david

Cheers,

Jianjie Lin

Hi all, 

We are very pleased to announce Version 2.5 release of ACRN. You can see the release blog from https://projectacrn.org/blog/ and detailed Release Notes in website https://projectacrn.github.io/latest/release_notes/release_notes_2.5.html

What’s New in v2.5

·       Nested Virtualization Technology Preview:

A brand-new concept, nested virtualization, is introduced as a preview in this v2.5 release. Nested virtualization lets you run virtual machine instances inside of a guest VM that’s running on the ACRN hypervisor. It’s designed to leverage the KVM/QEMU community’s rich feature set while keeping ACRN’s unique advantages in partition mode and hybrid mode. Read more in the Enable Nested Virtualization advanced guide.

·       Secure Boot Using EFI Stub:

EFI stub, previously retired in favor of using direct boot, returns as an alternative to end-to-end secure boot with Grub. The hypervisor, Service VM kernel, and prelaunched VM kernel are packaged into a single acrn.efi blob as an EFI application that can then be verified by the EFI BIOS. Read more in the Enable ACRN Secure Boot With EFI-Stub and Enable ACRN Secure Boot With GRUB advanced guides.

·       Modularization Improvements:

ACRN hypervisor modularization has been improved to be more scalable, including change to multiboot, interrupt handling, paging and memory management, and timers, with more to come in future releases.

·       Configuration and Build Process Improvements:

The ACRN configuration and build process continues to evolve from the changes made in the previous releases. For instructions using the build system, refer to Build ACRN From Source. For an introduction on the concepts and workflow of the configuration tools and processes, refer to Introduction to ACRN Configuration.

·       Document Updates:

With the changes to ACRN configuration, we made updates to the ACRN documentation around configuration, options, and parameters:

²  Introduction to ACRN Configuration

²  Scenario Configuration Options

²  Device Model Parameters

²  ACRN Kernel Parameters

New capabilities are documented here:

²  Enable Nested Virtualization

We’ve also made edits throughout the documentation to improve clarity, formatting, and presentation throughout the ACRN documentation:

²  Contribution Guidelines

²  Documentation Guidelines

²  AHCI Virtualization in Device Model

²  Device Passthrough

²  Hypercall / VHM Upcall

²  Timer

²  L1 Terminal Fault Mitigation

²  ACRN Hypervisor: Modular Design

²  Software Design Guidelines

²  Trusty TEE

²  Build ACRN From Source

²  Getting Started Guide

²  Supported Hardware

²  Enable ACRN Over QEMU/KVM

²  ACRN Documentation Generation

²  Enable Inter-VM Communication Based on Ivshmem

²  Run Debian as the Service VM

²  Trusty and Security Services Reference

²  Getting Started Guide for ACRN Hybrid Mode

²  Enable Serial Port on NUC

See the v2.5 full release notes and documentation for more information about this release including fixed and known issues.

Upgrading to v2.5 From Previous Releases

We highly recommended that you follow the instructions below to upgrade to v2.5 from previous ACRN releases.

·       Generate New Board XML

Board XML files, generated by ACRN board inspector, contain board information that is essential to build ACRN. Compared to previous versions, ACRN v2.5 extends the schema of board XMLs to summarize board information more systematically. You must regenerate your board XML file using the new board inspector when you upgrade to ACRN v2.5 to get the additional information needed for configuration.

Before using the new board inspector, ensure you have Python >= 3.6 on the target board and install the lxml PyPI package. Refer to Additional Dependencies for detailed steps to check and upgrade your Python version. The lxml package can be installed by executing the following command:

$ sudo pip3 install lxml 

Note: Refer to Using ACRN Configuration Toolset for a complete list of tools required to run the board inspector

With the prerequisites done, copy the entire board inspector folder from misc/config_tools/board_inspector to the target board, cd to that directory on the target, and run the board inspector tool using:

$ sudo python3 cli.py <my_board_name> 

This will generate <my_board_name>.xml in the current working directory. You’ll need to copy that XML file back to the host system to continue development.

·       Add New Configuration Options

In v2.5, the following elements are added to scenario XML files:

² hv.FEATURES.NVMX_ENABLED

² vm.PTM

The following element is renamed:

² hv.FEATURES.SSRAM.SSRAM_ENABLED (was hv.FEATURES.PSRAM.PSRAM_ENABLED in v2.4)

Constraints on values of the following element have changed:

² vm.guest_flags.guest_flag no longer accepts an empty text. For VMs with no guest flag set, set the value to 0.

Best & Regards

Terry

Hello everyone,

I am considering an experimental setup, using ACRN Hypervisor on top of Tiger Lake Platform.

I have seen that ACRN supports USB pass-through. How will it behave, if I want to use an AI USB stick (e.g. Intel Movidius USB stick)? How will it work with a multi-VM environment?

Thank you and best regards,

Feng. PAN

Hi Lonnie,

I’ll rely on the engineering team (@Chen, Jason CJ?) to help answer the question about being to run multiple pre-launched VMs.

The pre-launched VMs all use their own dedicate resources, there is no sharing possible across pre-launched VMs (inc. the Service VM). There is a communication channel you can establish between those based on shared memory (see our ivshmem documentation - https://projectacrn.github.io/latest/tutorials/enable_ivshmem.html).

Thanks,

Geoffroy