Hi Jianjie, I do not have any experience with the GPIO subsystem I’m afraid, @Xie, Nanlin, can you ask someone on the engineering team to help look at this? Thanks, Geoffroy

Hi Jianjie, This is good to know! We will keep that in mind, it will be good to have extra eyes looking at this when we develop this. Thanks, Geoffroy

Hi Feng, I am not well versed on CI tools and how they work. Our CI team is in China, and hence on holiday this week. Do you have full control of your test image? If so, you could build it so that it

Hi Jianjie, This is something we have been thinking about, i.e. using libvirt as the primary mechanism to handle the ACRN post-launched VM lifecycles. We will have to make sure we can implement all op

Hi Feng, There is no option to provide the user name and credentials for the User VM OS in the launch script. However, I believe there are ways to set-up the OS to auto-login for a specific user. But

Hi Jianjie, Thanks for all your answers. For the scheduler, please use SCHED_NOOP in the configuration tool: SCHEDULER (a child node of FEATURES): Specify the CPU scheduler used by the hypervisor. Sup

There are a couple of things we should tweak in your launch script: * Change the CPU affinity to 2,3,6,7. CPU #0 is also called the BSP (bootstrap) processor. It cannot be offlined and so it is always

Hi Jianjie,

Hi Jianjie, Regarding #1, you don’t need to modify the hypervisor for this. You can reconfigure the Service VM OS to boot in console mode. Assuming you are using Ubuntu, you can do so using “sudo syst

It looks like the QEMU set-up is slightly different. Could it be that you’re using libvirt for it and it’s setting up a NAT network? If true, that DHCP request gets handled locally on the machine and

Bummer. Did you specify a MAC address in your launch script (one that you know would be accepted by your DHCP server)? One thing that I guess could happen is that yoir infrastructure will not allow to

Hi Jianjie, The MAC address you specify there will be the MAC address you from within the User VM. Once you’ve booted the VM, run “ip a” in it, and the Ethernet interface should have that MAC address.

Hi Jianjie, Can you try to specify a MAC address in your launch script? E.g.: -s 4,virtio-net,<tap_name>,[mac=<XX:XX:XX:XX:XX:XX>] (from https://projectacrn.github.io/latest/developer-guides/hld/virti

Hi Jianjie, Can you send us the output of “ip a” after a reboot, confirm whether you have internet access and then the same output after launching the User VM? You don’t have any IP address (IPv4) ass

Hi Feng, These are accessible via the serial port interface. It’s the only way to have access to the ACRN shell. Do you have a serial port on your system? Thanks, Geoffroy

Thanks for the confirmation Jianjie Lin! You shouldn’t have to add more UUIDs to that file though, using different ones in each launch script (by adding the “-U” option) should be sufficient, were you

That header file contains a fixed (and static) list of UUIDs that can be used to launch VMs. I’m thinking that perhaps what is happening is the acrn-dm uses the same UUID by default for the second VM

Use different UUIDs in different launch scripts, pick any that is labeled as POST_STANDARD_VM_UUIDX in the https://github.com/projectacrn/acrn-hypervisor/blob/master/hypervisor/include/common/vm_uuids

Thanks for trying these out and confirming the results. Do you have any more info from the ACRN hypervisor over the serial port? As per my other email, I’m suspecting something wrong with the UUID bei

I’m suspicious of something wrong with the UUIDs. Can you try to add the UUID you want to use for the second VM to the launch script, using the “-U” option E.g.: -U 615db82a-e189-4b4f-8dbb-d321343e4ab