From: Viresh Kumar <viresh.kumar@linaro.org> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: "Linus Walleij" <linus.walleij@linaro.org>, "Bjorn Andersson" <bjorn.andersson@linaro.org>, "Bartosz Golaszewski" <bgolaszewski@baylibre.com>, "Enrico Weigelt, metux IT consult" <info@metux.net>, "Viresh Kumar" <vireshk@kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, "Jason Wang" <jasowang@redhat.com>, "Vincent Guittot" <vincent.guittot@linaro.org>, "Bill Mills" <bill.mills@linaro.org>, "Alex Bennée" <alex.bennee@linaro.org>, stratos-dev@op-lists.linaro.org, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, "Stefan Hajnoczi" <stefanha@redhat.com>, "Stefano Garzarella --cc virtualization @ lists . linux-foundation . org" <sgarzare@redhat.com>, virtualization@lists.linux-foundation.org, "Alistair Strachan" <astrachan@google.com> Subject: Re: [PATCH V3 1/3] gpio: Add virtio-gpio driver Date: Fri, 11 Jun 2021 13:31:22 +0530 [thread overview] Message-ID: <20210611080122.tlkidv6bowuka6fw@vireshk-i7> (raw) In-Reply-To: <CAMuHMdVrtSnFpPbB0P3Wxqm1D6vU1_cnh3ypsZJRNF6ueKdAsw@mail.gmail.com> On 11-06-21, 09:42, Geert Uytterhoeven wrote: > Hi Viresh, Linus, > > On Fri, Jun 11, 2021 at 5:56 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 10-06-21, 22:46, Linus Walleij wrote: > > > thanks for working on this, it's a really interesting driver. > > > > > > My first question is conceptual: > > > > > > We previously have Geerts driver for virtualization: > > > drivers/gpio/gpio-aggregator.c > > > > > > The idea with the aggregator is that a host script sets up a > > > unique gpiochip for the virtualized instance using some poking > > > in sysfs and pass that to the virtual machine. > > > So this is Linux acting as virtualization host by definition. > > The gpio-aggregator is running on the host... > > > > I think virtio is more abstract and intended for the usecase > > > where the hypervisor is not Linux, so this should be mentioned > > > in the commit, possibly also in Kconfig so users immediately > > > know what usecases the two different drivers are for. > > ... while the virtio-gpio driver is meant for the guest kernel. > > I my PoC "[PATCH QEMU v2 0/5] Add a GPIO backend"[1], I didn't have > a virtio transport, but just hooked into the PL061 GPIO emulation > in QEMU. The PL061 QEMU driver talked to the GPIO backend, which > talked to /dev/gpiochipN on the host. Hmm, interesting. > > Well, not actually. > > > > The host can actually be anything. It can be a Xen based dom0, which > > runs some proprietary firmware, or Qemu running over Linux. > > > > It is left for the host to decide how it wants to club together the > > GPIO pins from host and access them, with Linux host userspace it > > would be playing with /dev/gpiochipN, while for a raw one it may > > be accessing registers directly. > > > > And so the backend running at host, needs to pass the gpiochip > > configurations and only the host understand it. > > So QEMU has to translate the virtio-gpio communication to e.g. > /dev/gpiochipN on the host (or a different backend on non-Linux or > bare-metal HV). No, QEMU passes the raw messages to the backend daemon running in host userspace (which shares a socket with qemu). The backend understands the virtio/vhost protocols and so won't be required to change at all if we move from Qemu to something else. And that's what we (Linaro) are looking to do here with Project Stratos. Create virtio based hypervisor agnostic backends. > > The way I test it for now is by running this with Qemu over my x86 > > box, so my host side is indeed playing with sysfs Linux. > > Can you please share a link to the QEMU patches? Unfortunately, they aren't in good shape right now and the backend is a bit hacky (Just checking the data paths, but not touching /dev/gpiochipN at all for now). I didn't implement one as I am going to implement the backend in Rust and not Qemu. So it doesn't depend on Qemu at all. To give you an idea of the whole thing, here is what we have done for I2c for example, GPIO one will look very similar. The Qemu patches: https://yhbt.net/lore/all/cover.1617278395.git.viresh.kumar@linaro.org/T/ The stuff from tools/vhost-user-i2c/ directory (or patch 4/6) isn't used anymore and the following Rust implementation replaces it: https://github.com/vireshk/vhost-device/tree/master/src/i2c I can share the GPIO code once I have the Rust implementation ready. > The GPIO aggregator came into play after talking to Alexander Graf and > Peter Maydell. To reduce the attack surface, they didn't want QEMU > to be responsible for exporting to the guest a subset of all GPIOs of > a gpiochip, only a full gpiochip. However, the full gpiochip may > contain critical GPIOs you do not want the guest to tamper with. > Hence the GPIO aggregator was born, to take care of aggregating all > GPIOs you want to export to a guest into a new virtual gpiochip. > > You can find more information about the GPIO Aggregator's use cases in > "[PATCH v7 0/6] gpio: Add GPIO Aggregator"[2]. So I was actually looking to do some kind of aggregation on the host side's backend daemon to share only a subset of GPIO pins, I will see if that is something I can reuse. Thanks for sharing details. -- viresh
WARNING: multiple messages have this Message-ID (diff)
From: Viresh Kumar <viresh.kumar@linaro.org> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Alistair Strachan <astrachan@google.com>, Vincent Guittot <vincent.guittot@linaro.org>, Stefan Hajnoczi <stefanha@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, Viresh Kumar <vireshk@kernel.org>, Linus Walleij <linus.walleij@linaro.org>, virtualization@lists.linux-foundation.org, linux-kernel <linux-kernel@vger.kernel.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>, stratos-dev@op-lists.linaro.org, "Enrico Weigelt, metux IT consult" <info@metux.net>, Bill Mills <bill.mills@linaro.org> Subject: Re: [PATCH V3 1/3] gpio: Add virtio-gpio driver Date: Fri, 11 Jun 2021 13:31:22 +0530 [thread overview] Message-ID: <20210611080122.tlkidv6bowuka6fw@vireshk-i7> (raw) In-Reply-To: <CAMuHMdVrtSnFpPbB0P3Wxqm1D6vU1_cnh3ypsZJRNF6ueKdAsw@mail.gmail.com> On 11-06-21, 09:42, Geert Uytterhoeven wrote: > Hi Viresh, Linus, > > On Fri, Jun 11, 2021 at 5:56 AM Viresh Kumar <viresh.kumar@linaro.org> wrote: > > On 10-06-21, 22:46, Linus Walleij wrote: > > > thanks for working on this, it's a really interesting driver. > > > > > > My first question is conceptual: > > > > > > We previously have Geerts driver for virtualization: > > > drivers/gpio/gpio-aggregator.c > > > > > > The idea with the aggregator is that a host script sets up a > > > unique gpiochip for the virtualized instance using some poking > > > in sysfs and pass that to the virtual machine. > > > So this is Linux acting as virtualization host by definition. > > The gpio-aggregator is running on the host... > > > > I think virtio is more abstract and intended for the usecase > > > where the hypervisor is not Linux, so this should be mentioned > > > in the commit, possibly also in Kconfig so users immediately > > > know what usecases the two different drivers are for. > > ... while the virtio-gpio driver is meant for the guest kernel. > > I my PoC "[PATCH QEMU v2 0/5] Add a GPIO backend"[1], I didn't have > a virtio transport, but just hooked into the PL061 GPIO emulation > in QEMU. The PL061 QEMU driver talked to the GPIO backend, which > talked to /dev/gpiochipN on the host. Hmm, interesting. > > Well, not actually. > > > > The host can actually be anything. It can be a Xen based dom0, which > > runs some proprietary firmware, or Qemu running over Linux. > > > > It is left for the host to decide how it wants to club together the > > GPIO pins from host and access them, with Linux host userspace it > > would be playing with /dev/gpiochipN, while for a raw one it may > > be accessing registers directly. > > > > And so the backend running at host, needs to pass the gpiochip > > configurations and only the host understand it. > > So QEMU has to translate the virtio-gpio communication to e.g. > /dev/gpiochipN on the host (or a different backend on non-Linux or > bare-metal HV). No, QEMU passes the raw messages to the backend daemon running in host userspace (which shares a socket with qemu). The backend understands the virtio/vhost protocols and so won't be required to change at all if we move from Qemu to something else. And that's what we (Linaro) are looking to do here with Project Stratos. Create virtio based hypervisor agnostic backends. > > The way I test it for now is by running this with Qemu over my x86 > > box, so my host side is indeed playing with sysfs Linux. > > Can you please share a link to the QEMU patches? Unfortunately, they aren't in good shape right now and the backend is a bit hacky (Just checking the data paths, but not touching /dev/gpiochipN at all for now). I didn't implement one as I am going to implement the backend in Rust and not Qemu. So it doesn't depend on Qemu at all. To give you an idea of the whole thing, here is what we have done for I2c for example, GPIO one will look very similar. The Qemu patches: https://yhbt.net/lore/all/cover.1617278395.git.viresh.kumar@linaro.org/T/ The stuff from tools/vhost-user-i2c/ directory (or patch 4/6) isn't used anymore and the following Rust implementation replaces it: https://github.com/vireshk/vhost-device/tree/master/src/i2c I can share the GPIO code once I have the Rust implementation ready. > The GPIO aggregator came into play after talking to Alexander Graf and > Peter Maydell. To reduce the attack surface, they didn't want QEMU > to be responsible for exporting to the guest a subset of all GPIOs of > a gpiochip, only a full gpiochip. However, the full gpiochip may > contain critical GPIOs you do not want the guest to tamper with. > Hence the GPIO aggregator was born, to take care of aggregating all > GPIOs you want to export to a guest into a new virtual gpiochip. > > You can find more information about the GPIO Aggregator's use cases in > "[PATCH v7 0/6] gpio: Add GPIO Aggregator"[2]. So I was actually looking to do some kind of aggregation on the host side's backend daemon to share only a subset of GPIO pins, I will see if that is something I can reuse. Thanks for sharing details. -- viresh _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-06-11 8:02 UTC|newest] Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-06-10 12:09 [PATCH V3 0/3] gpio: Add virtio based driver Viresh Kumar 2021-06-10 12:09 ` Viresh Kumar 2021-06-10 12:16 ` [PATCH V3 1/3] gpio: Add virtio-gpio driver Viresh Kumar 2021-06-10 12:16 ` Viresh Kumar 2021-06-10 13:22 ` Arnd Bergmann 2021-06-10 16:00 ` Enrico Weigelt, metux IT consult [not found] ` <01000179f6a7715c-cd106846-7770-4088-bb7c-a696bfcbf83e-000000@email.amazonses.com> 2021-06-10 17:03 ` [Stratos-dev] " Jean-Philippe Brucker 2021-06-10 17:03 ` Jean-Philippe Brucker 2021-06-10 19:41 ` Arnd Bergmann 2021-06-14 10:21 ` Viresh Kumar 2021-06-14 10:21 ` Viresh Kumar 2021-06-14 12:31 ` Arnd Bergmann 2021-06-14 12:49 ` Vincent Guittot [not found] ` <0100017a0a9264cc-57668c56-fdbf-412a-9f82-9bf95f5c653e-000000@email.amazonses.com> 2021-06-14 12:58 ` [Stratos-dev] " Arnd Bergmann 2021-06-14 13:24 ` Vincent Guittot 2021-06-14 20:54 ` Arnd Bergmann 2021-06-15 7:30 ` Vincent Guittot 2021-06-10 15:54 ` Enrico Weigelt, metux IT consult 2021-06-10 16:57 ` Viresh Kumar 2021-06-10 16:57 ` Viresh Kumar 2021-06-10 20:46 ` Linus Walleij 2021-06-10 20:46 ` Linus Walleij 2021-06-11 3:56 ` Viresh Kumar 2021-06-11 3:56 ` Viresh Kumar 2021-06-11 7:42 ` Geert Uytterhoeven 2021-06-11 7:42 ` Geert Uytterhoeven 2021-06-11 8:01 ` Viresh Kumar [this message] 2021-06-11 8:01 ` Viresh Kumar 2021-06-11 8:22 ` Geert Uytterhoeven 2021-06-11 8:22 ` Geert Uytterhoeven 2021-06-15 11:15 ` Viresh Kumar 2021-06-15 11:15 ` Viresh Kumar 2021-06-15 11:37 ` Geert Uytterhoeven 2021-06-15 11:37 ` Geert Uytterhoeven 2021-06-15 20:03 ` Linus Walleij 2021-06-15 20:03 ` Linus Walleij 2021-06-16 1:45 ` Viresh Kumar 2021-06-16 1:45 ` Viresh Kumar 2021-06-14 8:07 ` Enrico Weigelt, metux IT consult 2021-06-14 8:12 ` Andy Shevchenko 2021-06-14 8:12 ` Andy Shevchenko 2021-06-14 9:14 ` Viresh Kumar 2021-06-14 9:14 ` Viresh Kumar 2021-06-14 9:17 ` Enrico Weigelt, metux IT consult 2021-06-14 9:52 ` Viresh Kumar 2021-06-14 9:52 ` Viresh Kumar 2021-06-14 9:12 ` Viresh Kumar 2021-06-14 9:12 ` Viresh Kumar 2021-06-14 9:29 ` Enrico Weigelt, metux IT consult 2021-06-14 8:03 ` Enrico Weigelt, metux IT consult 2021-06-14 9:24 ` Viresh Kumar 2021-06-14 9:24 ` Viresh Kumar 2021-06-16 3:30 ` Bjorn Andersson 2021-06-16 3:30 ` Bjorn Andersson 2021-06-16 15:52 ` Enrico Weigelt, metux IT consult 2021-06-18 9:13 ` Linus Walleij 2021-06-18 9:13 ` Linus Walleij 2021-06-21 17:25 ` Bjorn Andersson 2021-06-21 17:25 ` Bjorn Andersson 2021-06-10 12:16 ` [PATCH V3 2/3] gpio: virtio: Add IRQ support Viresh Kumar 2021-06-10 12:16 ` Viresh Kumar 2021-06-10 21:30 ` Linus Walleij 2021-06-10 21:30 ` Linus Walleij 2021-06-14 7:08 ` Viresh Kumar 2021-06-14 7:08 ` Viresh Kumar 2021-06-10 12:16 ` [PATCH V3 3/3] MAINTAINERS: Add entry for Virtio-gpio Viresh Kumar [not found] ` <01000179f5da7763-2ea817c6-e176-423a-952e-de02443f71e2-000000@email.amazonses.com> 2021-06-10 17:40 ` [PATCH V3 1/3] gpio: Add virtio-gpio driver Jean-Philippe Brucker 2021-06-10 17:40 ` Jean-Philippe Brucker 2021-06-11 3:39 ` Viresh Kumar 2021-06-11 3:39 ` Viresh Kumar [not found] ` <01000179f9276678-ae2bb25f-4c0c-4176-b906-650c585b9753-000000@email.amazonses.com> 2021-06-11 8:34 ` [Stratos-dev] " Arnd Bergmann 2021-06-14 5:26 ` Viresh Kumar 2021-06-14 5:26 ` Viresh Kumar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210611080122.tlkidv6bowuka6fw@vireshk-i7 \ --to=viresh.kumar@linaro.org \ --cc=alex.bennee@linaro.org \ --cc=astrachan@google.com \ --cc=bgolaszewski@baylibre.com \ --cc=bill.mills@linaro.org \ --cc=bjorn.andersson@linaro.org \ --cc=geert@linux-m68k.org \ --cc=info@metux.net \ --cc=jasowang@redhat.com \ --cc=linus.walleij@linaro.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mst@redhat.com \ --cc=sgarzare@redhat.com \ --cc=stefanha@redhat.com \ --cc=stratos-dev@op-lists.linaro.org \ --cc=vincent.guittot@linaro.org \ --cc=vireshk@kernel.org \ --cc=virtualization@lists.linux-foundation.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.