All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: David Stevens <stevensd@chromium.org>
Cc: "Gerd Hoffmann" <kraxel@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Zach Reizner" <zachr@chromium.org>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Tomeu Vizoso" <tomeu.vizoso@collabora.com>,
	"Tomasz Figa" <tfiga@chromium.org>,
	virtio-dev@lists.oasis-open.org,
	"Alexandros Frantzis" <alexandros.frantzis@collabora.co.uk>
Subject: Re: [virtio-dev] [RFC] Upstreaming virtio-wayland (or an alternative)
Date: Thu, 27 Feb 2020 10:09:51 +0100	[thread overview]
Message-ID: <20200227100951.19e5c8df@collabora.com> (raw)
In-Reply-To: <CAD=HUj5R_iOsCwaN85_nNUxo+3sp+QxR6bjPknqFM2Y+u0GOUg@mail.gmail.com>

On Thu, 27 Feb 2020 13:20:51 +0900
David Stevens <stevensd@chromium.org> wrote:

> > * manage a central UUID <-> 'struct file' map that allows virtio-pipe
> >   to convert FDs to UUIDs, pass UUIDs through a pipe and convert those
> >   UUIDs back to FDs on the other end
> >   - we need to expose an API to let each subsystem register/unregister
> >     their UUID <-> FD mapping (subsystems are responsible for the UUID
> >     creation/negotiation)  
> 
> Can you provide more detail about the envisioned scope of this
> framework?

The scope is "generic message+FD passing" interface, which is pretty
much what virtio-wl provides.

> What sort of FDs and subsystems will use the framework?

Basically any subsystem/driver that wants to share resources with the
other end (host/guest depending on where you place yourself):
virtio-gpu, virtio-vdev, virtio-fs, ...

As for the sort of FDs, it can be any kind of resources that needs to
be shared: dmabuf, virtio-ipc-connection, opened-file, ...

> How
> do operations on the guest FD affect the host FD, and vice versa?

Depends what you mean by operations. If we're talking about regular
read/write/ioctl/mmap operations on the guest side, it's up to the
subsystem/driver to implement the expected behavior. Note that on the
host side, we won't manipulate plain FDs since we are in userspace and
the 'struct file' abstraction does not exists there. There will be
local-FD <-> resource mappings though, but how this is done is
resource-type dependent (for IPC FDs we create a unix socket and bridge
it to the virtio-ipc connection, for video buffers we'll ask the
gpu/videodev to export the resource as a dmabuf, ...).

What's not entirely clear is whether we need to support cases where the
host create its own resources (without being asked by the guest) and
decides to pass them to a virtio-ipc-connection (through the unix <->
virtio-ipc bridge). If that's needed, we need interfaces to let host
apps import their resources in the VM (again, those interfaces are
likely to be resource-type dependent).

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2020-02-27  9:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 17:28 [virtio-dev] [RFC] Upstreaming virtio-wayland (or an alternative) Boris Brezillon
2020-02-10  5:06 ` [virtio-dev] " David Stevens
2020-02-17 10:02   ` Boris Brezillon
2020-02-17 10:22     ` David Stevens
2020-02-10 13:38 ` Gerd Hoffmann
2020-02-10 16:09   ` Stefan Hajnoczi
2020-02-17 10:28   ` Boris Brezillon
2020-02-17 12:32     ` Gerd Hoffmann
2020-02-17 13:44       ` Boris Brezillon
     [not found] ` <CADMs+9YC3QHOsmsB9pjA-AFC+fc=_a+tSqBbDsecNvkhBc85Dw@mail.gmail.com>
2020-02-17 11:02   ` Boris Brezillon
2020-02-17 13:58 ` Boris Brezillon
     [not found]   ` <CAFNex=BuHdsEjFK3_cTqO2nOE-kB_MSH26sCTekF_6AK8Fyv3Q@mail.gmail.com>
2020-02-17 18:21     ` Boris Brezillon
     [not found]       ` <CAFNex=A8fU3e=FYP=t7jQ0J2E5aoyGKujhj8Df+vOhkzV8etgA@mail.gmail.com>
2020-02-19  8:52         ` Boris Brezillon
2020-02-24 10:33       ` Boris Brezillon
2020-02-24 12:12         ` Gerd Hoffmann
2020-02-24 12:45           ` Boris Brezillon
2020-02-24 13:18             ` Boris Brezillon
2020-02-24 13:42               ` Gerd Hoffmann
2020-02-24 13:57                 ` Boris Brezillon
2020-02-24 14:25                   ` Boris Brezillon
2020-02-24 13:35             ` Gerd Hoffmann
2020-02-24 12:32       ` Gerd Hoffmann
2020-02-25 15:21 ` [virtio-dev] " Boris Brezillon
2020-02-25 15:55   ` Alex Bennée
2020-02-26  9:25     ` Boris Brezillon
2020-02-26 15:12   ` Gerd Hoffmann
2020-02-26 17:05     ` Boris Brezillon
2020-02-27 10:29       ` Gerd Hoffmann
2020-02-27 12:24         ` Boris Brezillon
2020-02-27  4:20   ` David Stevens
2020-02-27  9:09     ` Boris Brezillon [this message]
     [not found]       ` <CAFNex=C4wm7=iH9XmyHoTSdkDfA3vbFOuLaaQ4aLjE9keu_NDg@mail.gmail.com>
2020-02-27  9:33         ` Boris Brezillon
2020-02-27 11:14       ` David Stevens
2020-02-27 11:51         ` Boris Brezillon
2020-02-27 14:43         ` Gerd Hoffmann
2020-02-28  8:04           ` Boris Brezillon
2020-02-28  9:27             ` Gerd Hoffmann
2020-02-28 10:11               ` David Stevens
2020-02-28 10:30                 ` Gerd Hoffmann
2020-03-02  2:24                   ` David Stevens
2020-03-02  9:28                     ` Boris Brezillon
2020-02-28 10:31                 ` Boris Brezillon

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=20200227100951.19e5c8df@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=alexandros.frantzis@collabora.co.uk \
    --cc=kraxel@redhat.com \
    --cc=marcheu@chromium.org \
    --cc=stefanha@redhat.com \
    --cc=stevensd@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=tomeu.vizoso@collabora.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=zachr@chromium.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.