Hi Viresh, On Fri, Jun 11, 2021 at 10:01 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote: > On 11-06-21, 09:42, Geert Uytterhoeven wrote: > > On Fri, Jun 11, 2021 at 5:56 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> 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@xxxxxxxxxx/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@xxxxxxxxxxxxxx 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
