Exchange data between applications in different guests.

[rajesh datta]

Hello everybody,

I am working on a xvisor-based project that requires to create two guests on raspberry pi. Each guest hosts a separate Linux VM for safety reasons. The final goal is to run an application on each Linux which will send data (e.g., a single number for now) to the other. Could you please provide me some guidance on how to achieve this? Does xvisor support any appropriate API? I have also attached a small image for clarification.

Best Regards, 

Rajesh Kumar Datta

[Anup Patel]

Hi Rajesh,

You have two options for inter-Guest communication on same Host:

1. VirtIO Net - All existing guest types have one VirtIO network instance. You

can just assign different IP address to "eth0" in each Guest/VM and communicate

over TCP/IP sockets

2. VirtIO RPMSG - This is for point-to-point message passing between Guests/VMs.

For small messages VirtIO RPMSG will be much faster because we avoid Linux

network stack inside Guest. We have reference RPMSG client/server in Xvisor

sources at docs/examples/rpmsg_test.c

BTW, I would suggest to use Virt-v7 on RPi2 and Virt-v8 on RPi3 or higher.

Regards,

Anup

--
You received this message because you are subscribed to the Google Groups "Xvisor Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xvisor-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xvisor-devel/CAFGNbNBSmJyWet9wKiyU%3D3iC92gTEiBU1wHu4KnErJwKv9jXDw%40mail.gmail.com.

[rajesh datta]

Hello Anup,

Thank you very much for your help and your guidance. I will try both methods. However, I have a few more questions for each one of them and I would really appreciate if you could provide me some information.

1. VirtIO Net: Can the IP address be defined in the dts file or should it be set by the Linux VM (e.g., ifconfig eth0 192.168.1.5 netmask 255.255.255.0 up) ? Additionally, by checking the xvisor commands, I found the "ipconfig" command, which depends on CONFIG_NET_STACK. However, CONFIG_NET_STACK is not set in libs/netstack/openconf.cfg (default n) and CONFIG_NET is also not set in core/net/openconf.cfg. Should I enable them both for sockets to work?

2. VirtIO RPMSG: I am thinking to include this code as an executable on busybox and call it from user space. For that code we need to define rpmsg_device_path. In the arm .dts file I found the virtio-rpmsg0. Can I use this one or should I add a new entry?

Thank you again for hour help .

Best regards, 

Rajesh Datta

[Anup Patel]

Hi Rajesh,

Please see inline below ...

On Sun, Nov 3, 2019 at 8:44 AM rajesh datta <rajesh...@gmail.com> wrote:
>
> Hello Anup,
>
> Thank you very much for your help and your guidance. I will try both methods. However, I have a few more questions for each one of them and I would really appreciate if you could provide me some information.
>
> 1. VirtIO Net: Can the IP address be defined in the dts file or should it be set by the Linux VM (e.g., ifconfig eth0 192.168.1.5 netmask 255.255.255.0 up) ? Additionally, by checking the xvisor commands, I found the "ipconfig" command, which depends on CONFIG_NET_STACK. However, CONFIG_NET_STACK is not set in libs/netstack/openconf.cfg (default n) and CONFIG_NET is also not set in core/net/openconf.cfg. Should I enable them both for sockets to work?

The Guest/VM IP address can be set from within Guest Linux using
ifconfig command. You can also pass "ip" kernel parameter to Guest
Linux at boot-time using "linux_cmdline" command of Guest basic
firmware.

The Xvisor ipconfig command is for Xvisor network stack. This command
assigns an IP address for network daemons running as-part of Xvisor
and it does not have any effect on IP assigned to Guest Linux.

>
> 2. VirtIO RPMSG: I am thinking to include this code as an executable on busybox and call it from user space. For that code we need to define rpmsg_device_path. In the arm .dts file I found the virtio-rpmsg0. Can I use this one or should I add a new entry?

<rpmsg_device_path> is character device path for RPMSG inside Guest
Linux (e.g. /dev/rpmsg_ctrl0).

The /dev/rpmsg_ctrl0 is not automatically created after booting Guest
unless you have some udev scripts for automatically do this.

Whenever some other GuestY boots to Linux prompt, we will see the
following message in kernel log of GuestX:
"virtio_rpmsg_bus virtio3: creating channel rpmsg_chrdev addr 0x400"

Based on the above message, GuestX will have to use RPMSG channel
address 0x400 (i.e. 1024) to communicate with GuestY.

Using this channel address we can create RPMSG character device on
GuestX for sending messages to GuestY using following commands:
# echo rpmsg_chrdev >
/sys/bus/rpmsg/devices/virtio3.rpmsg_chrdev.-1.1024/driver_override
# echo virtio3.rpmsg_chrdev.-1.1024 > /sys/bus/rpmsg/drivers_probe

Once above commands run successfully, you will see /dev/rpmsg_ctrl0
device on GuestX. You can now use "/dev/rpmsg_ctrl0" as RPMSG device
path with rpmsg_test utility.

Regards,
Anup

>
> Thank you again for hour help .
>
>
> Best regards,
>
> Rajesh Datta
>
>
>
> On Wed, Oct 30, 2019 at 3:44 PM rajesh datta <rajesh...@gmail.com> wrote:
>>
>> Hello everybody,
>>
>> I am working on a xvisor-based project that requires to create two guests on raspberry pi. Each guest hosts a separate Linux VM for safety reasons. The final goal is to run an application on each Linux which will send data (e.g., a single number for now) to the other. Could you please provide me some guidance on how to achieve this? Does xvisor support any appropriate API? I have also attached a small image for clarification.
>>
>>
>>
>>
>>
>>

>> Best Regards,
>> Rajesh Kumar Datta
>

> --
> You received this message because you are subscribed to the Google Groups "Xvisor Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to xvisor-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/xvisor-devel/CAFGNbNDo83e_7Ve9gmvTWJjiYi2gQzCOwoM4%3DhHKaQ4EtTgXrg%40mail.gmail.com.