All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
	"Enrico Weigelt, metux IT consult" <info@metux.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Bartosz Golaszewski" <bgolaszewski@baylibre.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Anton Vorontsov" <anton@enomsg.org>,
	"Colin Cross" <ccross@android.com>,
	"Tony Luck" <tony.luck@intel.com>,
	"Linux Doc Mailing List" <linux-doc@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	"Bill Mills" <bill.mills@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH] drivers: gpio: add virtio-gpio guest driver
Date: Thu, 17 Jun 2021 11:54:16 +0200	[thread overview]
Message-ID: <116f8135-4ddf-e8fc-6838-94093702ec3d@metux.net> (raw)
In-Reply-To: <20210617035901.kfzps6kg2emthjf4@vireshk-i7>

On 17.06.21 05:59, Viresh Kumar wrote:

 > Okay, we figured out now that you _haven't_ subscribed to virtio lists
 > and so your stuff never landed in anyone's inbox. But you did send
 > something and didn't completely went away.

Actually, I am subscribed in the list. We already had debates on it,
including on your postings (but also other things). And the ascii
version of the spec actually landed on the list last year, we had
discussions about it there.

I've just had the problem that my patches didn't go through, which is
very strange, since I actually am on the list and other mails of mine
went through all the time. I'm now suspecting it's triggered by some
subtle difference between my regular mail clients and git send-email.

 > Since you started this all and still want to do it, I will take my
 > patches back and let you finish with what you started. I will help
 > review them.

Thank you very much.

Please don't me wrong, I really don't wanna any kind of power play, just
wanna get an technically good solution. If there had been any mis-
understandings at that point, I'm officially saying sorry here.

Let's be friends.

You mentioned you've been missing with my spec. Please come foreward and
tell us what exactly you're missing and what your use cases are.

Note that I've intentionally left off certain "more sophisticated"
functionality we find on *some* gpio controllers, eg. per-line irq
masking, pinmux settings for several reasons, e.g.:

* those are only implemented by some hardware
* often implemented in or at least need to be coordinated with other
   pieces of hw (e.g. in SoCs, pinmux is usually done in a separate
   device)
* it shall be possible to support even the most simple devices and
   have the more sophisticated things totally optional. minium
   requirements for silicon implementations should be the lowest possible
   (IOW: minimal number of logic gates)

 >> You sound like a politician that tries to push an hidden agenda,
 >> made by some secret interest group in the back room, against the
 >> people - like "resistance is futile".
 >
 > :)

Perhaps I've been a bit overreacting at that point. But: this is really
that kind of talking we hear from politicians and corporate leaders
since many years, whenever they wanna push something through that we the
people don't want. Politicians use that as a social engineering tool for
demotivating any resistance. Over heare in Germany this even had become
a meme, and folks from CCC made a radio show about and named by that
(the German word is "alternativlos" - in english: without any
alternative). No idea about other countries, maybe it's a cultural
issue, but over here, those kind of talking had become a red light.

Of course, I never intended to accuse you of being one of these people.
Sorry if there's been misunderstanding.


Let's get back to your implementation: you've mentioned you're routing
raw virtio traffic into userland, to some other process (outside VMMs
like qemu) - how exactly are you doing that ?

That could be interesting for completely different scenarios. For
example, I'm currently exploring how to get VirGL running between 
separate processes running under the same kernel instance (fow now we
only have the driver side inside VM and the device outside it), means
driver and device are running as separate processes.

The primary use case are containers that shall have really GPU generic
drivers, not knowing anything about the actual hardware on the host.
Currently, container workloads wanting to use a GPU need to have special
drivers for exactly the HW the host happens to have. This makes generic,
portable container images a tuff problem.

I haven't digged deeply into the matter, but some virtio-tap transport
could be an relatively easy (probably not the most efficient) way to
solve this problem. In that scanario it would like this:

* we have a "virgl server" (could be some X or wayland application, or
   completely own compositor) opens up the device-end of an "virtio-tap"
   transport and attaches its virtio-gpio device emulation on it.
* "virtio-tap" now creates a driver-end, kernel probes an virtio-gpu
   instance on this (also leading to a new DRI device)
* container runtime picks the new DRI device and maps it into the
   container(s)
   [ yet open question, whether one DRI device for many containers
     is enough ]
* container application sees that virtio-gpu DRI device and speaks to
   it (mesa->virgl backend)
* the "virgl-server" receives buffers and commands from via virtio and
   sends them to the host's GL or Gallium API.

Once we're already there, we might think whether it could make sense
putting virtio routing into kvm itself, instead of letting qemu catch
page faults and virtual irqs. Yet have to see whether that's a good
idea, but I can imagine some performance improvements here.



--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

WARNING: multiple messages have this Message-ID (diff)
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Linus Walleij" <linus.walleij@linaro.org>,
	"Enrico Weigelt, metux IT consult" <info@metux.net>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Bartosz Golaszewski" <bgolaszewski@baylibre.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Anton Vorontsov" <anton@enomsg.org>,
	"Colin Cross" <ccross@android.com>,
	"Tony Luck" <tony.luck@intel.com>,
	"Linux Doc Mailing List" <linux-doc@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	virtualization@lists.linux-foundation.org,
	linux-riscv <linux-riscv@lists.infradead.org>,
	"Vincent Guittot" <vincent.guittot@linaro.org>,
	"Bill Mills" <bill.mills@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [PATCH] drivers: gpio: add virtio-gpio guest driver
Date: Thu, 17 Jun 2021 11:54:16 +0200	[thread overview]
Message-ID: <116f8135-4ddf-e8fc-6838-94093702ec3d@metux.net> (raw)
In-Reply-To: <20210617035901.kfzps6kg2emthjf4@vireshk-i7>

On 17.06.21 05:59, Viresh Kumar wrote:

 > Okay, we figured out now that you _haven't_ subscribed to virtio lists
 > and so your stuff never landed in anyone's inbox. But you did send
 > something and didn't completely went away.

Actually, I am subscribed in the list. We already had debates on it,
including on your postings (but also other things). And the ascii
version of the spec actually landed on the list last year, we had
discussions about it there.

I've just had the problem that my patches didn't go through, which is
very strange, since I actually am on the list and other mails of mine
went through all the time. I'm now suspecting it's triggered by some
subtle difference between my regular mail clients and git send-email.

 > Since you started this all and still want to do it, I will take my
 > patches back and let you finish with what you started. I will help
 > review them.

Thank you very much.

Please don't me wrong, I really don't wanna any kind of power play, just
wanna get an technically good solution. If there had been any mis-
understandings at that point, I'm officially saying sorry here.

Let's be friends.

You mentioned you've been missing with my spec. Please come foreward and
tell us what exactly you're missing and what your use cases are.

Note that I've intentionally left off certain "more sophisticated"
functionality we find on *some* gpio controllers, eg. per-line irq
masking, pinmux settings for several reasons, e.g.:

* those are only implemented by some hardware
* often implemented in or at least need to be coordinated with other
   pieces of hw (e.g. in SoCs, pinmux is usually done in a separate
   device)
* it shall be possible to support even the most simple devices and
   have the more sophisticated things totally optional. minium
   requirements for silicon implementations should be the lowest possible
   (IOW: minimal number of logic gates)

 >> You sound like a politician that tries to push an hidden agenda,
 >> made by some secret interest group in the back room, against the
 >> people - like "resistance is futile".
 >
 > :)

Perhaps I've been a bit overreacting at that point. But: this is really
that kind of talking we hear from politicians and corporate leaders
since many years, whenever they wanna push something through that we the
people don't want. Politicians use that as a social engineering tool for
demotivating any resistance. Over heare in Germany this even had become
a meme, and folks from CCC made a radio show about and named by that
(the German word is "alternativlos" - in english: without any
alternative). No idea about other countries, maybe it's a cultural
issue, but over here, those kind of talking had become a red light.

Of course, I never intended to accuse you of being one of these people.
Sorry if there's been misunderstanding.


Let's get back to your implementation: you've mentioned you're routing
raw virtio traffic into userland, to some other process (outside VMMs
like qemu) - how exactly are you doing that ?

That could be interesting for completely different scenarios. For
example, I'm currently exploring how to get VirGL running between 
separate processes running under the same kernel instance (fow now we
only have the driver side inside VM and the device outside it), means
driver and device are running as separate processes.

The primary use case are containers that shall have really GPU generic
drivers, not knowing anything about the actual hardware on the host.
Currently, container workloads wanting to use a GPU need to have special
drivers for exactly the HW the host happens to have. This makes generic,
portable container images a tuff problem.

I haven't digged deeply into the matter, but some virtio-tap transport
could be an relatively easy (probably not the most efficient) way to
solve this problem. In that scanario it would like this:

* we have a "virgl server" (could be some X or wayland application, or
   completely own compositor) opens up the device-end of an "virtio-tap"
   transport and attaches its virtio-gpio device emulation on it.
* "virtio-tap" now creates a driver-end, kernel probes an virtio-gpu
   instance on this (also leading to a new DRI device)
* container runtime picks the new DRI device and maps it into the
   container(s)
   [ yet open question, whether one DRI device for many containers
     is enough ]
* container application sees that virtio-gpu DRI device and speaks to
   it (mesa->virgl backend)
* the "virgl-server" receives buffers and commands from via virtio and
   sends them to the host's GL or Gallium API.

Once we're already there, we might think whether it could make sense
putting virtio routing into kvm itself, instead of letting qemu catch
page faults and virtual irqs. Yet have to see whether that's a good
idea, but I can imagine some performance improvements here.



--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2021-06-17  9:54 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-15 17:49 [PATCH] drivers: gpio: add virtio-gpio guest driver Enrico Weigelt, metux IT consult
2021-06-15 17:49 ` Enrico Weigelt, metux IT consult
2021-06-16  8:31 ` Linus Walleij
2021-06-16  8:31   ` Linus Walleij
2021-06-16  8:31   ` Linus Walleij
2021-06-16 11:49   ` Viresh Kumar
2021-06-16 11:49     ` Viresh Kumar
2021-06-16 11:49     ` Viresh Kumar
2021-06-16 15:04     ` Enrico Weigelt, metux IT consult
2021-06-16 15:04       ` Enrico Weigelt, metux IT consult
2021-06-17  3:59       ` Viresh Kumar
2021-06-17  3:59         ` Viresh Kumar
2021-06-17  3:59         ` Viresh Kumar
2021-06-17  9:54         ` Enrico Weigelt, metux IT consult [this message]
2021-06-17  9:54           ` Enrico Weigelt, metux IT consult
2021-06-17 11:47           ` Viresh Kumar
2021-06-17 11:47             ` Viresh Kumar
2021-06-17 11:47             ` Viresh Kumar
2021-06-16 14:41   ` Enrico Weigelt, metux IT consult
2021-06-16 14:41     ` Enrico Weigelt, metux IT consult
2021-06-16 18:47   ` banned on virtio list ? [Re: [PATCH] drivers: gpio: add virtio-gpio guest driver] Enrico Weigelt, metux IT consult
2021-06-16 18:47     ` [virtio-dev] " Enrico Weigelt, metux IT consult
2021-06-16 18:47     ` Enrico Weigelt, metux IT consult
2021-06-16 21:18     ` [virtio-dev] " Chet Ensign
2021-06-16 21:18       ` Chet Ensign
  -- strict thread matches above, loose matches on Subject: below --
2020-11-27 18:30 [PATCH] drivers: gpio: add virtio-gpio guest driver Enrico Weigelt, metux IT consult
2020-11-27 18:30 ` Enrico Weigelt, metux IT consult
2020-11-27 18:45 ` Randy Dunlap
2020-11-27 18:45   ` Randy Dunlap
2020-11-27 18:45   ` Randy Dunlap
2020-12-03 19:01   ` Enrico Weigelt, metux IT consult
2020-12-03 19:01     ` Enrico Weigelt, metux IT consult
2020-11-27 19:33 ` kernel test robot
2020-11-27 19:33   ` kernel test robot
2020-11-27 19:33   ` kernel test robot
2020-11-27 19:33   ` kernel test robot
2020-11-29 20:11 ` Michael S. Tsirkin
2020-11-29 20:11   ` Michael S. Tsirkin
2020-11-29 20:11   ` Michael S. Tsirkin
2020-11-29 22:10 ` Jonathan Neuschäfer
2020-11-29 22:10   ` Jonathan Neuschäfer
2020-11-29 22:10   ` Jonathan Neuschäfer
2020-12-03 19:12   ` Enrico Weigelt, metux IT consult
2020-12-03 19:12     ` Enrico Weigelt, metux IT consult
2020-12-02 14:15 ` Bartosz Golaszewski
2020-12-02 14:15   ` Bartosz Golaszewski
2020-12-03 19:00   ` Enrico Weigelt, metux IT consult
2020-12-03 19:00     ` Enrico Weigelt, metux IT consult
2020-12-03 22:35     ` Michael Walle
2020-12-03 22:35       ` Michael Walle
2020-12-04  8:28       ` Enrico Weigelt, metux IT consult
2020-12-04  8:28         ` Enrico Weigelt, metux IT consult
2020-12-04  9:06         ` Michael Walle
2020-12-04  9:06           ` Michael Walle

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=116f8135-4ddf-e8fc-6838-94093702ec3d@metux.net \
    --to=lkml@metux.net \
    --cc=alex.bennee@linaro.org \
    --cc=anton@enomsg.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=bill.mills@linaro.org \
    --cc=ccross@android.com \
    --cc=corbet@lwn.net \
    --cc=info@metux.net \
    --cc=jasowang@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mst@redhat.com \
    --cc=tony.luck@intel.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=virtualization@lists.linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.