Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp384906pxj; Fri, 11 Jun 2021 01:25:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwBFkZx/Da02QiXBzdgqaQzbdH128qSBQjOL2Q0KhfZ5u/rjbiH/eWgDpT4thJgrtIh7Hsd X-Received: by 2002:a05:6402:4cf:: with SMTP id n15mr2608072edw.162.1623399943432; Fri, 11 Jun 2021 01:25:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623399943; cv=none; d=google.com; s=arc-20160816; b=CnoNnmWt1p3uoc7W86fjpAPlBiMJAQKSqvhZmbmy6lYzfccFcyvMPh76rq5VPwaKJK 6Z77U6+rIqYjbVgu5ZQnKyahC9YPejiYFAaRlsD/bbhmhhkt9DcZAUXNm/lkO6SxEK6O AZX/kOaj5bDMnf0w7S3mQTpFdv0RRmP5r2PnU0ISXsv7dBk/n2c2H+42BFzAvHQ4FyMY aQTAVNgZdwTeGrLKBTDq6kuPfaDUBhKWnqflhVwROkrl+/zTl9xUaKe80V2p9Pgelopj loVXBU+jgsu1WRCsqNP9ajf8dI7FmengD5MyIl0Ngcojs5ekUQM3241x31u6SomYTmom SIKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=DaNuOXRSxAprVjd9ifIAHGPCmMrvZ/ZSFrIGL+2Y/dE=; b=T9Z2TsNFumpONOInsO94skEhKlz0jl6uuttKDgqNN8KRTApR47e5RMbUWMQ0Un6Q8N /Ymeu+raJQi8M187g34cSAnwKwoZw0kh62YnZUt1KrYt0w3K1koeqMqVJ9kiJPQ6rqhd HoefmPD/lbow6T46gOv6D4m1n/MDMpVgvQi2VJIxo3WSARAHBJqe3d3O+blCtnZF39HK jT5xcqiH5Kt9xOeo9O7tS/r0J2aMwrgMxzXHb3zlFQyX7ObnFC29YDcCtQYoLfRV4XjP ynzy1q1m/15k12DLLOc05wUm7NnH50324vCxaOSd/y/s5KcnSYPbHELOnaQUL2r//j/M YBqg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e17si4849718ejm.271.2021.06.11.01.25.19; Fri, 11 Jun 2021 01:25:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230365AbhFKIYk (ORCPT + 99 others); Fri, 11 Jun 2021 04:24:40 -0400 Received: from mail-ua1-f50.google.com ([209.85.222.50]:33402 "EHLO mail-ua1-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229733AbhFKIYk (ORCPT ); Fri, 11 Jun 2021 04:24:40 -0400 Received: by mail-ua1-f50.google.com with SMTP id l12so2313320uai.0; Fri, 11 Jun 2021 01:22:42 -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=DaNuOXRSxAprVjd9ifIAHGPCmMrvZ/ZSFrIGL+2Y/dE=; b=fTUQj10ZAo9qvl5uIFPxOMX2vsjgZfzQz7CS5DfE+hqExwfZCY80PW4rrUu/ZmgnSO QUjhntPHjG/RiCcIu/A4iSaJlgQL5PwT5aFlAzA8ATy5vXHtcCn+7cLv/bu0r6U3/IxJ mrB81G4RhbKVRZmUU7iaTqjR2JevEX9Kd5zmPTDXEzITnMSANaSVA3VW1UGeabMV7Ht7 daI5sOe5v9Dzn2dKk6jZ2gaJt0v4WkjjHZZ986CuN2DGwWV50cwL0KrFFlYs3wr65jsB R/03gllN0uzQN9qA6D17Zb+t4CIa7qZ0wuozsyo8YVJ66mBlPVfvIKQILqMQIKxKMRjD fgZg== X-Gm-Message-State: AOAM5326Gcu/DaAjHXLSLz/K0KbEf9YE/FHiJRAZmPUM+dAxWz8t1L7Q 3Xd19+910V+/9RVFdjqaAuPtnS+aZB+OzlR1SU4= X-Received: by 2002:ab0:71d9:: with SMTP id n25mr1885900uao.2.1623399762314; Fri, 11 Jun 2021 01:22:42 -0700 (PDT) MIME-Version: 1.0 References: <10442926ae8a65f716bfc23f32339a6b35e51d5a.1623326176.git.viresh.kumar@linaro.org> <20210611035623.z4f2ynumzozigqnv@vireshk-i7> <20210611080122.tlkidv6bowuka6fw@vireshk-i7> In-Reply-To: <20210611080122.tlkidv6bowuka6fw@vireshk-i7> From: Geert Uytterhoeven Date: Fri, 11 Jun 2021 10:22:30 +0200 Message-ID: Subject: Re: [PATCH V3 1/3] gpio: Add virtio-gpio driver To: Viresh Kumar Cc: Linus Walleij , 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 , Wolfram Sang Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Viresh, On Fri, Jun 11, 2021 at 10:01 AM Viresh Kumar wrote: > On 11-06-21, 09:42, Geert Uytterhoeven wrote: > > 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. > > 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