From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Viresh Kumar <viresh.kumar@linaro.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>,
"Wolfram Sang" <wsa+renesas@sang-engineering.com>
Subject: Re: [PATCH V3 1/3] gpio: Add virtio-gpio driver
Date: Fri, 11 Jun 2021 10:22:30 +0200 [thread overview]
Message-ID: <CAMuHMdVL4VH09ixPcpqqokNJeYd68Th2Y6Lz4PZTF7h06OOBGw@mail.gmail.com> (raw)
In-Reply-To: <20210611080122.tlkidv6bowuka6fw@vireshk-i7>
Hi Viresh,
On Fri, Jun 11, 2021 at 10:01 AM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 11-06-21, 09:42, Geert Uytterhoeven wrote:
> > 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.
OK, IC.
> > > 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.
OK.
> 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.
Oh, you also have i2c. Nice!
> 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
Thanks for the links!
> > 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.
The same reasoning can apply to your backend daemon, so when using
the GPIO aggregator, you can just control a full gpiochip, without
having to implement access control on individual GPIO lines.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2021-06-11 8:22 UTC|newest]
Thread overview: 45+ 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:16 ` [PATCH V3 1/3] gpio: Add virtio-gpio driver 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 19:41 ` Arnd Bergmann
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 20:46 ` Linus Walleij
2021-06-11 3:56 ` Viresh Kumar
2021-06-11 7:42 ` Geert Uytterhoeven
2021-06-11 8:01 ` Viresh Kumar
2021-06-11 8:22 ` Geert Uytterhoeven [this message]
2021-06-15 11:15 ` Viresh Kumar
2021-06-15 11:37 ` Geert Uytterhoeven
2021-06-15 20:03 ` Linus Walleij
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 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: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-16 3:30 ` Bjorn Andersson
2021-06-16 15:52 ` Enrico Weigelt, metux IT consult
2021-06-18 9:13 ` Linus Walleij
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 21:30 ` Linus Walleij
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-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
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=CAMuHMdVL4VH09ixPcpqqokNJeYd68Th2Y6Lz4PZTF7h06OOBGw@mail.gmail.com \
--to=geert@linux-m68k.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=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=viresh.kumar@linaro.org \
--cc=vireshk@kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=wsa+renesas@sang-engineering.com \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).