- Stratos-dev - op-lists.linaro.org

[PATCH V8 0/2] virtio: Add specification for virtio-gpio

by Viresh Kumar

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

3 years, 1 month

4
16
0 0

Re: [Stratos-dev] [PATCH V4 2/2] gpio: virtio: Add IRQ support

by Arnd Bergmann

On Thu, Aug 5, 2021 at 1:26 PM Viresh Kumar via Stratos-dev <stratos-dev(a)op-lists.linaro.org> wrote: > > On 03-08-21, 17:01, Arnd Bergmann wrote: > > As far as I can tell, the update_irq_type() message would lead to the > > interrupt getting delivered when it was armed and is now getting disabled, > > but I don't see why we would call update_irq_type() as a result of the > > eventq notification. > > Based on discussion we had today (offline), I changed the design a bit > and used handle_level_irq() instead, as it provides consistent calls > to mask/unmask(), which simplified the whole thing a bit. The new flow looks much nicer to me, without the workqueue, and doing the requeue directly in the unmask() operation. I don't quite understand the purpose of the type_pending and mask_pending flags yet, can you explain what they actually do? Also, I have no idea about whether using the handle_level_irq() function is actually correct here. I suppose if necessary, the driver could provide its own irq.handler callback in place of that. > Also I have broken the rule from specs, maybe we should update spec > with that, where the specs said that the buffer must not be queued > before enabling the interrupt. I just queue the buffer unconditionally > now from unmask(). > > I am not sure but there may be some race around the "queued" flag and > I wonder if we can land in a scenario where the buffer is left > un-queued somehow, while an interrupt is enabled. Can that be integrated with the "masked" state now? It looks like the two flags are always opposites now. Arnd

3 years, 1 month

2
3
0 0

[PATCH V4 0/2] gpio: Add virtio based driver

by Viresh Kumar

Hello, This adds Virtio GPIO driver based on the proposed specification [1]. The specification for basic GPIO operations is already reviewed by Linus and Arnd, while the IRQ stuff is still under discussion and not finalized. I am sharing the code, so everyone gets more clarity on how it will work eventually in Linux. I have tested this patchset with Qemu guest with help of the libgpiod utility. I have also tested basic handling of interrupts on the guest side. It works as expected. The host side virtio-backend isn't ready yet and my tests only tested the flow control between guest and host, but didn't play with real GPIO pins. That will be done once I have a working backend in place (WIP). V3->V4: - Lots of changes, as the specification changed too much. Better forget everything we have done until now :) -- Viresh [1] https://lists.oasis-open.org/archives/virtio-dev/202107/msg00232.html Viresh Kumar (2): gpio: Add virtio-gpio driver gpio: virtio: Add IRQ support MAINTAINERS | 7 + drivers/gpio/Kconfig | 10 + drivers/gpio/Makefile | 1 + drivers/gpio/gpio-virtio.c | 648 +++++++++++++++++++++++++++++++ include/uapi/linux/virtio_gpio.h | 72 ++++ 5 files changed, 738 insertions(+) create mode 100644 drivers/gpio/gpio-virtio.c create mode 100644 include/uapi/linux/virtio_gpio.h -- 2.31.1.272.g89b43f80a514

3 years, 1 month

2
7
0 0

virtio-proxy approach for hypervisor-agnostic backend

by AKASHI Takahiro

Hi All, # Some of you might have received a similar message, the purpose # is the same, but for wider audience. I have been thinking of some idea of creating hypervisor-agnostic framework which will enable us to implement virtio device (backend) VMs on whatever the underlying hypervisor is. The aim is to create VMs as bare-metal applications using a small number of "common" vm services. I name this framework "virtio proxy"[1]. (You can think it as my solution proposal against the topic which Alex raised a concern on yesterday.) Now it is the time that we have to decide whether this approach can appeal to you and meet your requirements, and so if it is worth my continuing this study in the *next development cycle* which will start in September (or October). 1) Please give me your insights/feedback against my proposal. If we see no positive feedback or interest in the next two weeks or so, especially, from member company engineers, this study will be automatically *cancelled*. 2) If there is any interest seen, I will like to set up a dedicated Stratos call meeting in two weeks timeframe to discuss more. What is the best time slot for you? As I live in Japan, UTC-6, 7, or 8 (or even earlier) would be the best, but I would like to hear from member company engineers in West coast of USA, the timeslot is quite flexible. Here is my draft proposal: [1] https://docs.google.com/presentation/d/1jAOKbQpv44Rje74OI4pNKXlsCfRCQf547lH… Thanks, -Takahiro Akashi

3 years, 1 month

1
0
0 0

[PATCH V7 0/2] virtio: Add specification for virtio-gpio

by Viresh Kumar

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

3 years, 1 month

3
17
0 0

Meeting Canclled

by Mike Holmes

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."

3 years, 2 months

1
0
0 0

[PATCH V6 0/2] virtio: Add specification for virtio-gpio

by Viresh Kumar

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

3 years, 2 months

1
2
0 0

[PATCH v2 0/5] virtio: Add vhost-user based RNG

by Mathieu Poirier

This sets adds a vhost-user based random number generator (RNG), similar to what has been done for i2c and virtiofsd, with the implementation following the patterns already set forth in those. Applies cleanly to git://git.qemu.org/qemu.git master(1ea06abceec6). Thanks, Mathieu ----- New for V2: - Replaced "antropy" for "entropy" (Joakim). Mathieu Poirier (5): vhost-user-rng: Add vhost-user-rng implementation vhost-user-rng-pci: Add vhost-user-rng-pci implementation vhost-user-rng: backend: Add RNG vhost-user daemon implementation docs: Add documentation for vhost based RNG implementation MAINTAINERS: Add maintainer for vhost-user RNG implementation MAINTAINERS | 9 + docs/tools/vhost-user-rng.rst | 74 +++++ hw/virtio/Kconfig | 5 + hw/virtio/meson.build | 2 + hw/virtio/vhost-user-rng-pci.c | 79 +++++ hw/virtio/vhost-user-rng.c | 294 +++++++++++++++++ include/hw/virtio/vhost-user-rng.h | 33 ++ tools/meson.build | 8 + tools/vhost-user-rng/50-qemu-rng.json.in | 5 + tools/vhost-user-rng/main.c | 403 +++++++++++++++++++++++ tools/vhost-user-rng/meson.build | 10 + 11 files changed, 922 insertions(+) create mode 100644 docs/tools/vhost-user-rng.rst create mode 100644 hw/virtio/vhost-user-rng-pci.c create mode 100644 hw/virtio/vhost-user-rng.c create mode 100644 include/hw/virtio/vhost-user-rng.h create mode 100644 tools/vhost-user-rng/50-qemu-rng.json.in create mode 100644 tools/vhost-user-rng/main.c create mode 100644 tools/vhost-user-rng/meson.build -- 2.25.1

3 years, 2 months

2
8
0 0

Linaro Stratos agenda items for today

by Mike Holmes

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."

3 years, 2 months

1
0
0 0

AVPS2.0

by François Ozog

Hi FYI, Automotive Virtual Platform Specification V2.0 is out: https://at.projects.genivi.org/wiki/display/WIK4/2021/06/28/The+Automotive+… Cheers FF -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

3 years, 2 months

1
0
0 0

2024

2023

2022

2021

2020

Stratos-dev