Hi Arnold,

On Tue, Apr 19, 2022 at 02:24:03PM +0000, Florian Arnold wrote:

Hi everyone,

I am currently working on a system with real-time and non-realtime VMs, and I need to implement some network communication between different VMs and external components. I read the high-level design guides, especially the parts about device emulation and virtio, to understand what communication is already supported by ACRN. Unfortunately, I am not sure if I got it right so far. So maybe you guys could help me understand a few things.

My questions are:

* As I understand, I can connect two VMs with a virtual network. I assume this virtual communication is based on shared memory as well. Is that correct?

Yes. The virtio-network can support communication across post-launched
VMs and SOS. And virtio is a shared memory based PV solution.

* Is it possible to connect multiple VMs with something like a virtual switch? I'm thinking of something similar to virtual switches on ESXi Servers (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/virtual_networking_concepts.pdf)

Yes. The service VM will create a virtual switch/bridge that can connect
to both physical NIC and virtual NIC. You can refer following link:

https://projectacrn.github.io/latest/developer-guides/hld/virtio-net.html
https://projectacrn.github.io/1.6.1/tutorials/open_vswitch.html

* If something like a virtual switch exists in ACRN, does it live in the hypervisor itself or the service VM?

It lived in Service VM, so it only supports network communication across
SOS and post-launched VMs.

* Do pre-launched VMs always require dedicated hardware for network communication, or can they share devices emulated by the service VM?

Pre-launched VM doesn’t support virtio-network. Ivshmem and vuart are
the only ways for interacting across the pre-launched VM and other VMs.

Thanks
Yu

I hope those are not too many questions. Even some answers would help me a lot.

I appreciate any help you can provide.

Best
Florian

Hi Yu,
Thanks for the quick response. Your answers helped a lot. 

Just one more thing: 
The virtual switch (the standard L2 switch or the OVS) runs within the service VM, which is not a real-time VM.
So my question is:
Could other applications within the SOS user space or kernel space interfere with the switch so that I might get non-deterministic latencies for the communication between VMs and external components? 
If yes, are there any alternative approaches to ensure deterministic low-latency communication within ACRN?

Best
Florian

 

On Wed, Apr 20, 2022 at 04:09:08AM -0700, florian.r.e.arnold@... wrote:

Hi Yu,
Thanks for the quick response. Your answers helped a lot.

Just one more thing:
The virtual switch (the standard L2 switch or the OVS) runs within the service VM, which is not a real-time VM.

Do you want to get a realtime network mediator for realtime workloads in
RTVM? I don't think there has such mediator can saitisfy the RT
requirement so far... The hv-land mediator may be feasible as its code
path is determined but SOS's user-land mediator is too complex...

So my question is:
Could other applications within the SOS user space or kernel space interfere with the switch so that I might get non-deterministic latencies for the communication between VMs and external components?
If yes, are there any alternative approaches to ensure deterministic low-latency communication within ACRN?

You can investigate the QoS of Linux network for this. Likes cgroups or
others to isolate the bandwidth and prioritization.

Best
Florian