Page Comparison

...

Steps to replicate setup:

------------------------

[Mostly a copy/paste from README in xen-vhost-frontend]

Key components

Xen

• URL: https://github.com/vireshk/xen/tree/

• Branch: master

(You can use upstream Xen as well.)

...

$ ./configure --libdir=/usr/lib --build=x86_64-unknown-linux-gnu --host=aarch64-linux-gnu \
  --disable-docs --disable-golang --disable-ocamltools \
  --with-system-qemu=/root/qemu/build/i386-softmmu/qemu-system-i386

$ make -j9 debball CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64

Building the xen-vhost-frontend binary

• URL: https://github.com/vireshk/xen-vhost-frontend

• Branch: virtio-msg

Build as:

cargo build --bin xen-vhost-frontend --release --all-features --target aarch64-unknown-linux-gnu`gnu

Generated binary: target/aarch64-unknown-linux-gnu/release/xen-vhost-frontend

Building the vhost-device-i2c binary

• URL: https://github.com/rust-vmm/vhost-device/tree/

• Branch: main

These are Rust based hypervisor-agnostic `vhost-user` backends, maintained inside the rust-vmm project.

Build as:

cargo build --bin vhost-device-i2c --release --all-features --target aarch64-unknown-linux-gnu

Generated binary: target/aarch64-unknown-linux-gnu/release/vhost-device-i2c

[HACK: If GPIO or something else fails to build, then just comment them in Cargo.toml.]

...

Linux Kernel, guest and host

• URL: git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git

• Branch: virtio/msg

Build the kernel for aarch64 and you will get host kernel's image.

...

The following steps lets one test I2C `vhostvhost-device` device on Xen.

Run Xen via Qemu on X86 machine:

$ qemu-system-aarch64 -machine virt,virtualization=on -cpu cortex-a57 -serial mon:stdio \
  -device virtio-net-pci,netdev=net0 -netdev user,id=net0,hostfwd=tcp::8022-:22 \
  -drive file=/home/debian-bullseye-arm64.qcow2,index=0,id=hd0,if=none,format=qcow2 \
  -device virtio-scsi-pci -device scsi-hd,drive=hd0 \
  -display none -m 8192 -smp 8 -kernel /home/xen/xen \
  -append "dom0_mem=5G,max:5G dom0_max_vcpus=7 loglvl=all guest_loglvl=all" \
  -device guest-loader,addr=0x46000000,kernel=/home/Image,bootargs="root=/dev/sda2 console=hvc0 earlyprintk=xen" \
  -device ds1338,address=0x20

The `ds1338` ds1338 entry here is required to create a virtual I2C based RTC device on Dom0.

...

This tells the I2C backend to hook up to `/root/i2c.sock0` sock0 socket and wait for the master to start transacting.

The I2C controller used here on Dom0 is named `90c000090c0000.i2c` i2c (can be read from `/sys/bus/i2c/devices/i2c-0/name`name) and `32` 32 here matches the device on I2C bus set in the previous commands (`0x20`0x20).

Then start xen-vhost-frontend, by providing path of the socket to the master side. This by default will create grant-mapping for the memory regions (buffers mapped on the fly).

$ /root/xen-vhost-frontend/target/release/xen-vhost-frontend --socket-path /root/'

Now that all the preparations are done, lets start the guest.

The guest kernel should have Virtio related config options enabled, along with `i2ci2c-virtio` virtio driver.

$ xl create -c domu.conf

The guest should boot now. Once the guest is up, you can create the I2C based RTC device and use it.

Following will create `/dev/rtc0` rtc0 in the guest, which you can configure with the standard `hwclock` hwclock utility.

$ echo ds1338 0x20 > /sys/bus/i2c/devices/i2c-0/new_device

Sample domu.conf

kernel="/root/Image"
memory=512
vcpus=3
command="console=hvc0 earlycon=xenboot"
name="domu"
virtio = [ "type=virtio,device22, transport=mmio, grant_usage=1" ]

The device type here defines the device to be emulated on the guest. The type value is set with the DT `compatible` string of the device.

For example, it is `virtiovirtio,device22` device22 for I2C.

...

Hopefully this should be enough to replicate the setup at your end.

...