Hello,
In my earlier attempt [1], I implemented the vhost-user-i2c backend deamon for QEMU (though the code was generic enough to be used with any hypervisor).
And here is a Rust implementation of the vhost-user-i2c backend daemon. Again this is generic enough to be used with any hypervisor and can live in its own repository now:
https://github.com/vireshk/vhost-user-i2c
I am not sure what's the process to get this merged to Rust-vmm. Can someone help ? Is that the right thing to do ?
-------------------------8<-------------------------
Here are other details (which are same since the earlier Qemu attempt):
This is an initial implementation of a generic vhost-user backend for the I2C bus. This is based of the virtio specifications (already merged) for the I2C bus.
The kernel virtio I2C driver is still under review, here [2] is the latest version (v10):
The backend is implemented as a vhost-user device because we want to experiment in making portable backends that can be used with multiple hypervisors. We also want to support backends isolated in their own separate service VMs with limited memory cross-sections with the principle guest. This is part of a wider initiative by Linaro called "project Stratos" for which you can find information here:
https://collaborate.linaro.org/display/STR/Stratos+Home
I2C Testing: ------------
I didn't have access to a real hardware where I can play with a I2C client device (like RTC, eeprom, etc) to verify the working of the backend daemon, so I decided to test it on my x86 box itself with hierarchy of two ARM64 guests.
The first ARM64 guest was passed "-device ds1338,address=0x20" option, so it could emulate a ds1338 RTC device, which connects to an I2C bus. Once the guest came up, ds1338 device instance was created within the guest kernel by doing:
echo ds1338 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
[ Note that this may end up binding the ds1338 device to its driver, which won't let our i2c daemon talk to the device. For that we need to manually unbind the device from the driver:
echo 0-0020 > /sys/bus/i2c/devices/0-0020/driver/unbind ]
After this is done, you will get /dev/rtc1. This is the device we wanted to emulate, which will be accessed by the vhost-user-i2c backend daemon via the /dev/i2c-0 file present in the guest VM.
At this point we need to start the backend daemon and give it a socket-path to talk to from qemu (you can pass -v to it to get more detailed messages):
target/debug/vhost-user-i2c --socket-path=vi2c.sock -l 0:32
[ Here, 0:32 is the bus/device mapping, 0 for /dev/i2c-0 and 32 (i.e. 0x20) is client address of ds1338 that we used while creating the device. ]
Now we need to start the second level ARM64 guest (from within the first guest) to get the i2c-virtio.c Linux driver up. The second level guest is passed the following options to connect to the same socket:
-chardev socket,path=vi2c.sock,id=vi2c \ -device vhost-user-i2c-pci,chardev=vi2c,id=i2c
Once the second level guest boots up, we will see the i2c-virtio bus at /sys/bus/i2c/devices/i2c-X/. From there we can now make it emulate the ds1338 device again by doing:
echo ds1338 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
[ This time we want ds1338's driver to be bound to the device, so it should be enabled in the kernel as well. ]
And we will get /dev/rtc1 device again here in the second level guest. Now we can play with the rtc device with help of hwclock utility and we can see the following sequence of transfers happening if we try to update rtc's time from system time.
hwclock -w -f /dev/rtc1 (in guest2) -> Reaches i2c-virtio.c (Linux bus driver in guest2) -> transfer over virtio -> Reaches the qemu's vhost-i2c device emulation (running over guest1) -> Reaches the backend daemon vhost-user-i2c started earlier (in guest1) -> ioctl(/dev/i2c-0, I2C_RDWR, ..); (in guest1) -> reaches qemu's hw/rtc/ds1338.c (running over host)
SMBUS Testing: --------------
I wasn't required to have such a tedious setup for testing out with SMBUS devices. I was able to emulate a SMBUS device on my x86 machine using i2c-stub driver.
$ modprobe i2c-stub chip_addr=0x20 //Boot the arm64 guest now with i2c-virtio driver and then do: $ echo al3320a 0x20 > /sys/class/i2c-adapter/i2c-0/new_device $ cat /sys/bus/iio/devices/iio:device0/in_illuminance_raw
That's it.
I hope I was able to give a clear picture of my test setup here :)
Viresh,
For rust-vmm, you need to create the new issue in the right project. You can probably pick up vmm-reference project at rust-vmm and ask for the new crate. You can also send email to rust-vmm mailing list but github "issues" feature is used heavily in the rust-vmm project. There is also bi-weekly meetings which is attended by me, Vatsa and rust-vmm developers where it can be put up as agenda.
The minimal requirement for the new crate is to have less (or almost none) dependencies on other crates so that they can be independently tested in the rust-vmm CI. Anyways, please file a new issue and I will ask Vatsa and others to comment there.
https://github.com/rust-vmm/vhost-user-backend http://lists.opendev.org/pipermail/rust-vmm/2021-March/000406.html
---Trilok Soni
-----Original Message----- From: Viresh Kumar viresh.kumar@linaro.org Sent: Wednesday, April 28, 2021 5:23 AM To: stratos-dev@op-lists.linaro.org; rust-vmm@lists.opendev.org Cc: Vincent Guittot vincent.guittot@linaro.org; Mike Holmes mike.holmes@linaro.org; Bill Mills bill.mills@linaro.org; Alex Bennée alex.bennee@linaro.org; Arnd Bergmann arnd.bergmann@linaro.com; Jie Deng jie.deng@intel.com; qemu-devel@nongnu.org; Trilok Soni tsoni@quicinc.com Subject: [RUST] Add crate for generic vhost-user-i2c backend daemon
------------------------------------------------------------------------- CAUTION: This email originated from outside of the organization. -------------------------------------------------------------------------
Hello,
In my earlier attempt [1], I implemented the vhost-user-i2c backend deamon for QEMU (though the code was generic enough to be used with any hypervisor).
And here is a Rust implementation of the vhost-user-i2c backend daemon. Again this is generic enough to be used with any hypervisor and can live in its own repository now:
https://github.com/vireshk/vhost-user-i2c
I am not sure what's the process to get this merged to Rust-vmm. Can someone help ? Is that the right thing to do ?
-------------------------8<-------------------------
Here are other details (which are same since the earlier Qemu attempt):
This is an initial implementation of a generic vhost-user backend for the I2C bus. This is based of the virtio specifications (already merged) for the I2C bus.
The kernel virtio I2C driver is still under review, here [2] is the latest version (v10):
The backend is implemented as a vhost-user device because we want to experiment in making portable backends that can be used with multiple hypervisors. We also want to support backends isolated in their own separate service VMs with limited memory cross-sections with the principle guest. This is part of a wider initiative by Linaro called "project Stratos" for which you can find information here:
https://collaborate.linaro.org/display/STR/Stratos+Home
I2C Testing: ------------
I didn't have access to a real hardware where I can play with a I2C client device (like RTC, eeprom, etc) to verify the working of the backend daemon, so I decided to test it on my x86 box itself with hierarchy of two ARM64 guests.
The first ARM64 guest was passed "-device ds1338,address=0x20" option, so it could emulate a ds1338 RTC device, which connects to an I2C bus. Once the guest came up, ds1338 device instance was created within the guest kernel by doing:
echo ds1338 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
[ Note that this may end up binding the ds1338 device to its driver, which won't let our i2c daemon talk to the device. For that we need to manually unbind the device from the driver:
echo 0-0020 > /sys/bus/i2c/devices/0-0020/driver/unbind ]
After this is done, you will get /dev/rtc1. This is the device we wanted to emulate, which will be accessed by the vhost-user-i2c backend daemon via the /dev/i2c-0 file present in the guest VM.
At this point we need to start the backend daemon and give it a socket-path to talk to from qemu (you can pass -v to it to get more detailed messages):
target/debug/vhost-user-i2c --socket-path=vi2c.sock -l 0:32
[ Here, 0:32 is the bus/device mapping, 0 for /dev/i2c-0 and 32 (i.e. 0x20) is client address of ds1338 that we used while creating the device. ]
Now we need to start the second level ARM64 guest (from within the first guest) to get the i2c-virtio.c Linux driver up. The second level guest is passed the following options to connect to the same socket:
-chardev socket,path=vi2c.sock,id=vi2c \ -device vhost-user-i2c-pci,chardev=vi2c,id=i2c
Once the second level guest boots up, we will see the i2c-virtio bus at /sys/bus/i2c/devices/i2c-X/. From there we can now make it emulate the ds1338 device again by doing:
echo ds1338 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
[ This time we want ds1338's driver to be bound to the device, so it should be enabled in the kernel as well. ]
And we will get /dev/rtc1 device again here in the second level guest. Now we can play with the rtc device with help of hwclock utility and we can see the following sequence of transfers happening if we try to update rtc's time from system time.
hwclock -w -f /dev/rtc1 (in guest2) -> Reaches i2c-virtio.c (Linux bus driver in guest2) -> transfer over virtio -> Reaches the qemu's vhost-i2c device emulation (running over guest1) -> Reaches the backend daemon vhost-user-i2c started earlier (in guest1) -> ioctl(/dev/i2c-0, I2C_RDWR, ..); (in guest1) -> reaches qemu's hw/rtc/ds1338.c (running over host)
SMBUS Testing: --------------
I wasn't required to have such a tedious setup for testing out with SMBUS devices. I was able to emulate a SMBUS device on my x86 machine using i2c-stub driver.
$ modprobe i2c-stub chip_addr=0x20 //Boot the arm64 guest now with i2c-virtio driver and then do: $ echo al3320a 0x20 > /sys/class/i2c-adapter/i2c-0/new_device $ cat /sys/bus/iio/devices/iio:device0/in_illuminance_raw
That's it.
I hope I was able to give a clear picture of my test setup here :)
-- viresh
[1] https://lore.kernel.org/qemu-devel/cover.1617278395.git.viresh.kumar@linaro.... [2] https://lore.kernel.org/lkml/226a8d5663b7bb6f5d06ede7701eedb18d1bafa1.161649...
Hi, I didn't realize that you had already CCed the rust-vmm mailing list, so anyways it is a good start.
-----Original Message----- From: Trilok Soni Sent: Wednesday, April 28, 2021 10:14 AM To: Viresh Kumar viresh.kumar@linaro.org; stratos-dev@op-lists.linaro.org; rust-vmm@lists.opendev.org Cc: Vincent Guittot vincent.guittot@linaro.org; Mike Holmes mike.holmes@linaro.org; Bill Mills bill.mills@linaro.org; Alex Bennée alex.bennee@linaro.org; Arnd Bergmann arnd.bergmann@linaro.com; Jie Deng jie.deng@intel.com; qemu-devel@nongnu.org Subject: RE: [RUST] Add crate for generic vhost-user-i2c backend daemon
Viresh,
For rust-vmm, you need to create the new issue in the right project. You can probably pick up vmm-reference project at rust-vmm and ask for the new crate. You can also send email to rust-vmm mailing list but github "issues" feature is used heavily in the rust-vmm project. There is also bi-weekly meetings which is attended by me, Vatsa and rust-vmm developers where it can be put up as agenda.
The minimal requirement for the new crate is to have less (or almost none) dependencies on other crates so that they can be independently tested in the rust-vmm CI. Anyways, please file a new issue and I will ask Vatsa and others to comment there.
https://github.com/rust-vmm/vhost-user-backend http://lists.opendev.org/pipermail/rust-vmm/2021-March/000406.html
---Trilok Soni
-----Original Message----- From: Viresh Kumar viresh.kumar@linaro.org Sent: Wednesday, April 28, 2021 5:23 AM To: stratos-dev@op-lists.linaro.org; rust-vmm@lists.opendev.org Cc: Vincent Guittot vincent.guittot@linaro.org; Mike Holmes mike.holmes@linaro.org; Bill Mills bill.mills@linaro.org; Alex Bennée alex.bennee@linaro.org; Arnd Bergmann arnd.bergmann@linaro.com; Jie Deng jie.deng@intel.com; qemu-devel@nongnu.org; Trilok Soni tsoni@quicinc.com Subject: [RUST] Add crate for generic vhost-user-i2c backend daemon
------------------------------------------------------------------------- CAUTION: This email originated from outside of the organization. -------------------------------------------------------------------------
Hello,
In my earlier attempt [1], I implemented the vhost-user-i2c backend deamon for QEMU (though the code was generic enough to be used with any hypervisor).
And here is a Rust implementation of the vhost-user-i2c backend daemon. Again this is generic enough to be used with any hypervisor and can live in its own repository now:
https://github.com/vireshk/vhost-user-i2c
I am not sure what's the process to get this merged to Rust-vmm. Can someone help ? Is that the right thing to do ?
-------------------------8<-------------------------
Here are other details (which are same since the earlier Qemu attempt):
This is an initial implementation of a generic vhost-user backend for the I2C bus. This is based of the virtio specifications (already merged) for the I2C bus.
The kernel virtio I2C driver is still under review, here [2] is the latest version (v10):
The backend is implemented as a vhost-user device because we want to experiment in making portable backends that can be used with multiple hypervisors. We also want to support backends isolated in their own separate service VMs with limited memory cross-sections with the principle guest. This is part of a wider initiative by Linaro called "project Stratos" for which you can find information here:
https://collaborate.linaro.org/display/STR/Stratos+Home
I2C Testing: ------------
I didn't have access to a real hardware where I can play with a I2C client device (like RTC, eeprom, etc) to verify the working of the backend daemon, so I decided to test it on my x86 box itself with hierarchy of two ARM64 guests.
The first ARM64 guest was passed "-device ds1338,address=0x20" option, so it could emulate a ds1338 RTC device, which connects to an I2C bus. Once the guest came up, ds1338 device instance was created within the guest kernel by doing:
echo ds1338 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
[ Note that this may end up binding the ds1338 device to its driver, which won't let our i2c daemon talk to the device. For that we need to manually unbind the device from the driver:
echo 0-0020 > /sys/bus/i2c/devices/0-0020/driver/unbind ]
After this is done, you will get /dev/rtc1. This is the device we wanted to emulate, which will be accessed by the vhost-user-i2c backend daemon via the /dev/i2c-0 file present in the guest VM.
At this point we need to start the backend daemon and give it a socket-path to talk to from qemu (you can pass -v to it to get more detailed messages):
target/debug/vhost-user-i2c --socket-path=vi2c.sock -l 0:32
[ Here, 0:32 is the bus/device mapping, 0 for /dev/i2c-0 and 32 (i.e. 0x20) is client address of ds1338 that we used while creating the device. ]
Now we need to start the second level ARM64 guest (from within the first guest) to get the i2c-virtio.c Linux driver up. The second level guest is passed the following options to connect to the same socket:
-chardev socket,path=vi2c.sock,id=vi2c \ -device vhost-user-i2c-pci,chardev=vi2c,id=i2c
Once the second level guest boots up, we will see the i2c-virtio bus at /sys/bus/i2c/devices/i2c-X/. From there we can now make it emulate the ds1338 device again by doing:
echo ds1338 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
[ This time we want ds1338's driver to be bound to the device, so it should be enabled in the kernel as well. ]
And we will get /dev/rtc1 device again here in the second level guest. Now we can play with the rtc device with help of hwclock utility and we can see the following sequence of transfers happening if we try to update rtc's time from system time.
hwclock -w -f /dev/rtc1 (in guest2) -> Reaches i2c-virtio.c (Linux bus driver in guest2) -> transfer over virtio -> Reaches the qemu's vhost-i2c device emulation (running over guest1) -> Reaches the backend daemon vhost-user-i2c started earlier (in guest1) -> ioctl(/dev/i2c-0, I2C_RDWR, ..); (in guest1) -> reaches qemu's hw/rtc/ds1338.c (running over host)
SMBUS Testing: --------------
I wasn't required to have such a tedious setup for testing out with SMBUS devices. I was able to emulate a SMBUS device on my x86 machine using i2c-stub driver.
$ modprobe i2c-stub chip_addr=0x20 //Boot the arm64 guest now with i2c-virtio driver and then do: $ echo al3320a 0x20 > /sys/class/i2c-adapter/i2c-0/new_device $ cat /sys/bus/iio/devices/iio:device0/in_illuminance_raw
That's it.
I hope I was able to give a clear picture of my test setup here :)
-- viresh
[1] https://lore.kernel.org/qemu-devel/cover.1617278395.git.viresh.kumar@linaro.... [2] https://lore.kernel.org/lkml/226a8d5663b7bb6f5d06ede7701eedb18d1bafa1.161649...
On 28-04-21, 17:13, Trilok Soni wrote:
Viresh,
For rust-vmm, you need to create the new issue in the right project. You can probably pick up vmm-reference project at rust-vmm and ask for the new crate.
Done.
https://github.com/rust-vmm/vmm-reference/issues/118
There is also bi-weekly meetings which is attended by me, Vatsa and rust-vmm developers where it can be put up as agenda.
That would be great.
The minimal requirement for the new crate is to have less (or almost none) dependencies on other crates so that they can be independently tested in the rust-vmm CI.
It depends on a bunch of crates, specially vhost and vhost-user-backend.
Anyways, please file a new issue and I will ask Vatsa and others to comment there.
Thanks Trilok.
On 29-04-21, 12:39, Viresh Kumar wrote:
On 28-04-21, 17:13, Trilok Soni wrote:
Viresh,
For rust-vmm, you need to create the new issue in the right project. You can probably pick up vmm-reference project at rust-vmm and ask for the new crate.
Done.
The issue got moved a bit and we have received good response as of now.
https://github.com/rust-vmm/community/issues/106
Thanks Viresh.
Top posting since somehow I am not getting rust-vmm group emails on my open-source email ID subscription. I have received Vatsa's email on the Hypervisor crate on rust-vmm mailing list but not this one. I am not sure you are receiving the rust-vmm bi-weekly meeting invites, i2c crate was discussed this week.
https://etherpad.opendev.org/p/rust-vmm-sync-2021 - notes from the meeting and I have forwarded series to you.
---Trilok Soni
-----Original Message----- From: Viresh Kumar viresh.kumar@linaro.org Sent: Wednesday, May 19, 2021 9:01 PM To: Trilok Soni tsoni@quicinc.com Cc: stratos-dev@op-lists.linaro.org; rust-vmm@lists.opendev.org; Vincent Guittot vincent.guittot@linaro.org; Mike Holmes mike.holmes@linaro.org; Bill Mills bill.mills@linaro.org; Alex Bennée alex.bennee@linaro.org; Arnd Bergmann arnd.bergmann@linaro.com; Jie Deng jie.deng@intel.com; qemu-devel@nongnu.org Subject: Re: [RUST] Add crate for generic vhost-user-i2c backend daemon
------------------------------------------------------------------------- CAUTION: This email originated from outside of the organization. -------------------------------------------------------------------------
On 29-04-21, 12:39, Viresh Kumar wrote:
On 28-04-21, 17:13, Trilok Soni wrote:
Viresh,
For rust-vmm, you need to create the new issue in the right project. You can probably pick up vmm-reference project at rust-vmm and ask for the new crate.
Done.
The issue got moved a bit and we have received good response as of now.
https://github.com/rust-vmm/community/issues/106
-- viresh
On 20-05-21, 05:03, Trilok Soni wrote:
Thanks Viresh.
Top posting since somehow I am not getting rust-vmm group emails on my open-source email ID subscription. I have received Vatsa's email on the Hypervisor crate on rust-vmm mailing list but not this one.
I am not sure you are receiving the rust-vmm bi-weekly meeting invites,
No, I am not.
i2c crate was discussed this week.
https://etherpad.opendev.org/p/rust-vmm-sync-2021 - notes from the meeting and I have forwarded series to you.
Yeah, someone posted this on the i2c issue as well.
On 28-04-21, 17:52, Viresh Kumar wrote:
Hello,
In my earlier attempt [1], I implemented the vhost-user-i2c backend deamon for QEMU (though the code was generic enough to be used with any hypervisor).
And here is a Rust implementation of the vhost-user-i2c backend daemon. Again this is generic enough to be used with any hypervisor and can live in its own repository now:
FWIW, I have updated the implementation to support multiple guests now.
On 28-04-21, 17:52, Viresh Kumar wrote:
Hello,
In my earlier attempt [1], I implemented the vhost-user-i2c backend deamon for QEMU (though the code was generic enough to be used with any hypervisor).
And here is a Rust implementation of the vhost-user-i2c backend daemon. Again this is generic enough to be used with any hypervisor and can live in its own repository now:
A new crate is added in rust-vmm for this and here is the new repo I am using:
https://github.com/vireshk/vhost-device
And here is the discussion happening on my PULL request.
https://github.com/rust-vmm/vhost-device/pull/1
stratos-dev@op-lists.linaro.org
-
Trilok Soni -
Viresh Kumar