Hello,
This patchset adds vhost-user-i2c device's support in Qemu. Initially I tried to
add the backend implementation as well into Qemu, but as I was looking for a
hypervisor agnostic backend implementation, I decided to keep it outside of
Qemu. Eventually I implemented it in Rust and it works very well with this
patchset, and it is under review [1] to be merged in common rust vhost devices
crate.
The kernel virtio I2C driver [2] is fully reviewed and is ready to be merged soon.
V1->V2:
- Dropped the backend support from qemu and minor cleanups.
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):
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.sock0,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
Viresh Kumar (3):
hw/virtio: add boilerplate for vhost-user-i2c device
hw/virtio: add vhost-user-i2c-pci boilerplate
MAINTAINERS: Add entry for virtio-i2c
MAINTAINERS | 7 +
hw/virtio/Kconfig | 5 +
hw/virtio/meson.build | 2 +
hw/virtio/vhost-user-i2c-pci.c | 69 +++++++
hw/virtio/vhost-user-i2c.c | 288 +++++++++++++++++++++++++++++
include/hw/virtio/vhost-user-i2c.h | 28 +++
6 files changed, 399 insertions(+)
create mode 100644 hw/virtio/vhost-user-i2c-pci.c
create mode 100644 hw/virtio/vhost-user-i2c.c
create mode 100644 include/hw/virtio/vhost-user-i2c.h
--
2.31.1.272.g89b43f80a514
Hello,
This patchset adds virtio specification for GPIO devices. It supports basic GPIO
line operations, along with optional interrupts on them (in a separate patch).
This is an *alternative implementation* of the virtio-gpio specification, a
different version of it was earlier posted by Enrico [1].
I took back V4 of the specification I posted earlier (on June 17th), to allow
Enrico to come up with something that is robust and works for everyone (as he
started this thing last year), but it didn't go as expected. I couldn't
see any of my review comments being incorporated (or any intentions of them
getting in ever) in the three versions Enrico posted until now.
This patchset is already reviewed by Linus (GPIO Maintainer) and Arnd.
Key differences from Enrico's approach [1]:
- config structure is rearranged to remove everything apart from number of gpios
and size of the gpio_names_field.
- Request/free is merged with set-direction itself.
- Interrupt implementation handled with feature bit 0. Either the interrupts are
fully supported or not at all.
- All non-interrupt traffic happens on a single virtqueue, requestq. Interrupt
traffic goes over eventq.
- Doesn't add any ordering restrictions on the device for different GPIO lines,
it can respond earlier to the second request, while still processing the first
one.
Version history of the my changes:
V7 -> V8:
- Use fixed-length struct virtio_gpio_response for all requests and define a
separate structure for get-names.
- Explicitly write the expected values of direction in the get/set-direction
tables.
- Better/detailed interrupt handling information, based on fast-eoi mechanism
now, where the driver notifies the device only once after the interrupt is
handled.
- Added reviewed-by tags collected so far.
V6 -> V7:
- Drop Activate/Deactivate requests and merge them with set-direction one.
- Dropped separate calls to set direction to input or output (with a value),
with a single call to set-direction (input, output, or none). Note that the
driver needs to call set-value before calling set-direction-out now.
- Allow multiple messages for a GPIO line to be sent together, they must be
processed in order though.
- The gpio-line names aren't required to be set for all the lines now, it is
optional and can be present only for a subset of lines. Provided example as
well.
- Merge irq-set/mask/unmask to a single set-irq-type message.
- We have only 6 message types now instead of 11 in v6.
- Mentioned about non-atomic nature of the these messages in commit log for
patch 1/2.
- Improved spec content overall.
V5 -> V6:
- All non-interrupt traffic happens on a single virtqueue, requestq. Interrupt
traffic goes over eventq now.
- Many fields dropped from the config structure.
- Separate message type to get gpio-names, added more description about how the
names should be.
- Much clearer message flows, both non-irq messages and irq-messages.
- Parallelism supported for all type of messages, for different GPIO pins.
- All references to POSIX errors dropped, just reply pass or fail.
- request/free renamed to activate/deactivate, as that's what we will end up
doing there, activate or deactivate a GPIO line.
- General purpose IO as I/O or Input/Output instead.
- Hopefully I didn't miss any review comments.
V4 -> V5:
- Split into two patches, irq stuff in patch 2.
- Use separate virtqueue for sending data from device/driver.
- Allow parallel processing of requests for different GPIOs, only one request at
a time for the same GPIO line.
- Same goes for interrupt side, only one interrupt request per GPIO line.
- Improved formatting in general.
- Add new sections explaining message flow sequence.
V3 -> V4:
- The GPIO line names must be unique within a device.
- The gpio_names[0] field is dropped and gpio_names_offset field is
added in place of the 2 bytes of padding.
- New interrupts must not be initiated by the device, without a response
for the previous one.
V2 -> V3:
- Unused char in name string should be marked 0 now.
- s/host/device/ and s/guest/driver/
- Added a new feature for IRQ mode, VIRTIO_GPIO_F_IRQ.
- A new feature should be added for Version information if required
later on.
V1 -> V2:
- gpio_names_size is 32 bit.
- gpio field is 16 bit.
- padding added 16 bit.
- Added packed attribute to few structures
- Add the missing 'type' field to the request
- Dropped to _nodata request/responses to simplify a bit, updated
related text.
--
Viresh
[1] https://lists.oasis-open.org/archives/virtio-dev/202106/msg00030.html
Viresh Kumar (2):
virtio-gpio: Add the device specification
virtio-gpio: Add support for interrupts
conformance.tex | 30 ++-
content.tex | 1 +
virtio-gpio.tex | 578 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 605 insertions(+), 4 deletions(-)
create mode 100644 virtio-gpio.tex
--
2.31.1.272.g89b43f80a514
Hello,
This patchset adds virtio specification for GPIO devices. It supports basic GPIO
line operations, along with optional interrupts on them (in a separate patch).
This is an *alternative implementation* of the virtio-gpio specification, a
different version of it was earlier posted by Enrico [1].
I took back V4 of the specification I posted earlier (on June 17th), to allow
Enrico to come up with something that is robust and works for everyone (as he
started this thing last year), but it didn't go as expected. I couldn't
see any of my review comments being incorporated (or any intentions of them
getting in ever) in the three versions Enrico posted.
And so I am trying to present an alternative approach here to solve the problem,
which I believe is more clear and robust. I am open to suggestions to improve it
further.
I will let the virtio/gpio maintainers decide on its fate.
Key differences from Enrico's approach [1]:
- config structure is rearranged to remove everything apart from number of gpios
and size of the gpio_names_field.
- Request/free is merged with set-direction itself.
- Interrupt implementation handled with feature bit 0. Either the interrupts are
fully supported or not at all.
- All non-interrupt traffic happens on a single virtqueue, requestq. Interrupt
traffic goes over eventq.
- Doesn't add any ordering restrictions on the device for different GPIO lines,
it can respond earlier to the second request, while still processing the first
one.
Version history of the specification I sent:
V6 -> V7:
- Drop Activate/Deactivate requests and merge them with set-direction one.
- Dropped separate calls to set direction to input or output (with a value),
with a single call to set-direction (input, output, or none). Note that the
driver needs to call set-value before calling set-direction-out now.
- Allow multiple messages for a GPIO line to be sent together, they must be
processed in order though.
- The gpio-line names aren't required to be set for all the lines now, it is
optional and can be present only for a subset of lines. Provided example as
well.
- Merge irq-set/mask/unmask to a single set-irq-type message.
- We have only 6 message types now instead of 11 in v6.
- Mentioned about non-atomic nature of the these messages in commit log for
patch 1/2.
- Improved spec content overall.
V5 -> V6:
- All non-interrupt traffic happens on a single virtqueue, requestq. Interrupt
traffic goes over eventq now.
- Many fields dropped from the config structure.
- Separate message type to get gpio-names, added more description about how the
names should be.
- Much clearer message flows, both non-irq messages and irq-messages.
- Parallelism supported for all type of messages, for different GPIO pins.
- All references to POSIX errors dropped, just reply pass or fail.
- request/free renamed to activate/deactivate, as that's what we will end up
doing there, activate or deactivate a GPIO line.
- General purpose IO as I/O or Input/Output instead.
- Hopefully I didn't miss any review comments.
V4 -> V5:
- Split into two patches, irq stuff in patch 2.
- Use separate virtqueue for sending data from device/driver.
- Allow parallel processing of requests for different GPIOs, only one request at
a time for the same GPIO line.
- Same goes for interrupt side, only one interrupt request per GPIO line.
- Improved formatting in general.
- Add new sections explaining message flow sequence.
V3 -> V4:
- The GPIO line names must be unique within a device.
- The gpio_names[0] field is dropped and gpio_names_offset field is
added in place of the 2 bytes of padding.
- New interrupts must not be initiated by the device, without a response
for the previous one.
V2 -> V3:
- Unused char in name string should be marked 0 now.
- s/host/device/ and s/guest/driver/
- Added a new feature for IRQ mode, VIRTIO_GPIO_F_IRQ.
- A new feature should be added for Version information if required
later on.
V1 -> V2:
- gpio_names_size is 32 bit.
- gpio field is 16 bit.
- padding added 16 bit.
- Added packed attribute to few structures
- Add the missing 'type' field to the request
- Dropped to _nodata request/responses to simplify a bit, updated
related text.
--
Viresh
[1] https://lists.oasis-open.org/archives/virtio-dev/202106/msg00030.html
Viresh Kumar (2):
virtio-gpio: Add the device specification
virtio-gpio: Add support for interrupts
conformance.tex | 30 ++-
content.tex | 1 +
virtio-gpio.tex | 528 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 555 insertions(+), 4 deletions(-)
create mode 100644 virtio-gpio.tex
--
2.31.1.272.g89b43f80a514
Hi All
I have a prior commitment, and Alex is unable to host the call due to
internet issues, normal service will resume for the next call.
Mike
--
Mike Holmes (he / him / his) | Director, Performance & Enablement, Linaro
Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
"Work should be fun and collaborative; the rest follows."
Hello,
This patchset adds virtio specification for GPIO devices. It supports basic GPIO
line operations, along with optional interrupts on them (in a separate patch).
This is an *alternative implementation* of the virtio-gpio specification, a
different version of it was earlier posted by Enrico [1].
I took back V4 of the specification I posted earlier (on June 17th), to allow
Enrico to come up with something that is robust and works for everyone (as he
started this thing last year), but it didn't go as expected. I couldn't
see any of my review comments being incorporated (or any intentions of them
getting in ever) in the two versions Enrico posted and a month passed since
then.
And so I am trying to present an alternative approach here to solve the problem,
which I believe is more clear and robust. I am open to suggestions to improve it
further.
I will let the virtio/gpio maintainers decide on its fate.
Key differences from Enrico's approach [1]:
- config structure is rearranged to remove everything apart from number of gpios
and size of the gpio_names_field.
- Supports freeing of a GPIO line after use, we call them activate/deactivate
now, which suits their purpose better.
- Interrupt implementation handled with feature bit 0. Either the interrupts are
fully supported or not at all.
- All non-interrupt traffic happens on a single virtqueue, requestq. Interrupt
traffic goes over eventq.
- Doesn't add any ordering restrictions on the device, it can respond earlier to
the second request, while still processing the first one.
- Clearly state that two requests can't be initiated for the same line by device
or driver.
Version history of the specification I sent:
V5 -> V6:
- All non-interrupt traffic happens on a single virtqueue, requestq. Interrupt
traffic goes over eventq now.
- Many fields dropped from the config structure.
- Separate message type to get gpio-names, added more description about how the
names should be.
- Much clearer message flows, both non-irq messages and irq-messages.
- Parallelism supported for all type of messages, for different GPIO pins.
- All references to POSIX errors dropped, just reply pass or fail.
- request/free renamed to activate/deactivate, as that's what we will end up
doing there, activate or deactivate a GPIO line.
- General purpose IO as I/O or Input/Output instead.
- Hopefully I didn't miss any review comments.
V4 -> V5:
- Split into two patches, irq stuff in patch 2.
- Use separate virtqueue for sending data from device/driver.
- Allow parallel processing of requests for different GPIOs, only one request at
a time for the same GPIO line.
- Same goes for interrupt side, only one interrupt request per GPIO line.
- Improved formatting in general.
- Add new sections explaining message flow sequence.
V3 -> V4:
- The GPIO line names must be unique within a device.
- The gpio_names[0] field is dropped and gpio_names_offset field is
added in place of the 2 bytes of padding.
- New interrupts must not be initiated by the device, without a response
for the previous one.
V2 -> V3:
- Unused char in name string should be marked 0 now.
- s/host/device/ and s/guest/driver/
- Added a new feature for IRQ mode, VIRTIO_GPIO_F_IRQ.
- A new feature should be added for Version information if required
later on.
V1 -> V2:
- gpio_names_size is 32 bit.
- gpio field is 16 bit.
- padding added 16 bit.
- Added packed attribute to few structures
- Add the missing 'type' field to the request
- Dropped to _nodata request/responses to simplify a bit, updated
related text.
--
Viresh
[1] https://lists.oasis-open.org/archives/virtio-dev/202106/msg00030.html
Viresh Kumar (2):
virtio-gpio: Add the device specification
virtio-gpio: Add support for interrupts
conformance.tex | 30 ++-
content.tex | 1 +
virtio-gpio.tex | 608 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 635 insertions(+), 4 deletions(-)
create mode 100644 virtio-gpio.tex
--
2.31.1.272.g89b43f80a514
Hi All
A small agenda today, probably you have been following the GPIO discussions
on the mailing list already.
If you have topics please let me know
Agenda [1]
-
Updates
-
[Mike] Should we try to build a secure booting, secure VM Xen based
demo, Ilias has found issues with the attestation of the VMs, is that
something we should try to address?
[1]
https://linaro.atlassian.net/wiki/spaces/STR/pages/28562751538/2021-07-08+P…
--
Mike Holmes (he / him / his) | Director, Foundation Technologies, Linaro
Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
"Work should be fun and collaborative; the rest follows."
