From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76DA3C48BE0 for ; Fri, 11 Jun 2021 07:42:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5A31C60BD3 for ; Fri, 11 Jun 2021 07:42:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231582AbhFKHos (ORCPT ); Fri, 11 Jun 2021 03:44:48 -0400 Received: from mail-ua1-f49.google.com ([209.85.222.49]:42624 "EHLO mail-ua1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230467AbhFKHor (ORCPT ); Fri, 11 Jun 2021 03:44:47 -0400 Received: by mail-ua1-f49.google.com with SMTP id w5so2250881uaq.9; Fri, 11 Jun 2021 00:42:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=38AX8dJKliZcm5SjDtUlGVi/FFnBmE/O/3FCvxTZd8o=; b=e/c8wmnOG85MLUh0MrDxoC5JNqYtaoac35MMXV2adhStyJhooDuykAap/BV25pJo2p tAeAo/nMG0bQqBQEDEPP7ENen4I45xokCcdZE1ks9OinXK/pyEMJ3paxSBc5Qd5yxjaj 1Garf9AfeFJA4CJV26GK1jPQJQEZQITNYfo/Uo47QyKXvQAGqSqpIyVR3VZSQvy3Pqv+ U+0pxCykyOwWWrunifFd7jdbVogX5gcl6dxal6lF17Tqo6U8yF8sBU/Y94rf1EbkagZC 4/e3cIzFIDVJJxCeCRUZvyP58joLOxU2LLDIxROPiu1eDygLz/pvxswapI6rqWp9snzK diNQ== X-Gm-Message-State: AOAM533OtCAcGVQMAb7+UuV60cB0t9yxoQuLUJOMwSiwHnLneGL1AJPt 6Slykho5zff1Y1Is16LodHNK/TSzMSoXJ6mUJPQ= X-Google-Smtp-Source: ABdhPJyC0lhpoHIsnRTYb/jBHTXjzOjCm5sNgTxgszrrtuP+35/7N0zzkKE5Xb0wL4kG5xU1+tZftlhPDtoDlti9U/0= X-Received: by 2002:ab0:63d9:: with SMTP id i25mr1758952uap.106.1623397353672; Fri, 11 Jun 2021 00:42:33 -0700 (PDT) MIME-Version: 1.0 References: <10442926ae8a65f716bfc23f32339a6b35e51d5a.1623326176.git.viresh.kumar@linaro.org> <20210611035623.z4f2ynumzozigqnv@vireshk-i7> In-Reply-To: <20210611035623.z4f2ynumzozigqnv@vireshk-i7> From: Geert Uytterhoeven Date: Fri, 11 Jun 2021 09:42:22 +0200 Message-ID: Subject: Re: [PATCH V3 1/3] gpio: Add virtio-gpio driver To: Viresh Kumar , Linus Walleij Cc: Bjorn Andersson , Bartosz Golaszewski , "Enrico Weigelt, metux IT consult" , Viresh Kumar , "Michael S. Tsirkin" , Jason Wang , Vincent Guittot , Bill Mills , =?UTF-8?B?QWxleCBCZW5uw6ll?= , stratos-dev@op-lists.linaro.org, "open list:GPIO SUBSYSTEM" , linux-kernel , Stefan Hajnoczi , "Stefano Garzarella --cc virtualization @ lists . linux-foundation . org" , virtualization@lists.linux-foundation.org, Alistair Strachan Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Viresh, Linus, On Fri, Jun 11, 2021 at 5:56 AM Viresh Kumar 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. > 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). > 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? > > Possibly both could be used: aggregator to pick out the GPIOs > > you want into a synthetic GPIO chip, and the actual talk > > between the hypervisor/host and the guest using virtio, even > > with linux-on-linux. > > Not sure if I understand the aggregator thing for now, but we see the > backend running at host (which talks to this Linux driver at guest) as > a userspace thing and not a kernel driver. Not sure if aggregator can > be used like that, but anyway.. 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]. [1] https://lore.kernel.org/linux-gpio/20200423090118.11199-1-geert+renesas@glider.be [2] https://lore.kernel.org/linux-doc/20200511145257.22970-1-geert+renesas@glider.be/ 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