[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Dec 2019 15:48:38 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Geert Uytterhoeven <geert+renesas@...der.be>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
Jonathan Corbet <corbet@....net>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Harish Jenny K N <harish_kandiga@...tor.com>,
Eugeniu Rosca <erosca@...adit-jv.com>,
Alexander Graf <graf@...zon.com>,
Peter Maydell <peter.maydell@...aro.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Phil Reid <preid@...ctromag.com.au>,
Marc Zyngier <marc.zyngier@....com>,
Christoffer Dall <christoffer.dall@....com>,
Magnus Damm <magnus.damm@...il.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Linux Doc Mailing List <linux-doc@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
QEMU Developers <qemu-devel@...gnu.org>
Subject: Re: [PATCH v3 6/7] docs: gpio: Add GPIO Aggregator/Repeater documentation
Hi Linus,
On Thu, Dec 12, 2019 at 3:42 PM Linus Walleij <linus.walleij@...aro.org> wrote:
> On Wed, Nov 27, 2019 at 9:43 AM Geert Uytterhoeven
> <geert+renesas@...der.be> wrote:
> > +The GPIO Aggregator allows access control for individual GPIOs, by aggregating
> > +them into a new gpio_chip, which can be assigned to a group or user using
> > +standard UNIX file ownership and permissions. Furthermore, this simplifies and
> > +hardens exporting GPIOs to a virtual machine, as the VM can just grab the full
> > +GPIO controller, and no longer needs to care about which GPIOs to grab and
> > +which not, reducing the attack surface.
> > +
> > +Aggregated GPIO controllers are instantiated and destroyed by writing to
> > +write-only attribute files in sysfs.
>
> I suppose virtual machines will have a lengthy config file where
> they specify which GPIO lines to pick and use for their GPIO
> aggregator, and that will all be fine, the VM starts and the aggregator
> is there and we can start executing.
>
> I would perhaps point out a weakness as with all sysfs and with the current
> gpio sysfs: if a process creates an aggregator device, and then that
> process crashes, what happens when you try to restart the process and
> run e.g. your VM again?
>
> Time for a hard reboot? Or should we add some design guidelines for
> these machines so that they can cleanly tear down aggregators
> previously created by the crashed VM?
No, the VM does not create the aggregator.
The idea is for the user to create one or more aggregators, set up
permissions on /dev/gpiochipX, and launch the VM, passing the aggregated
/dev/gpiochipX as parameters.
If the VM crashes, just launch it again.
Destroying the aggregators is a manual and independent process, after
the VM has exited.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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
Powered by blists - more mailing lists