All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Zach Reizner" <zachr@chromium.org>,
	"David Stevens" <stevensd@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 13:24:25 +0100	[thread overview]
Message-ID: <20200227132425.1138be49@collabora.com> (raw)
In-Reply-To: <20200227102917.vuey2acv5ziizwnb@sirius.home.kraxel.org>

On Thu, 27 Feb 2020 11:29:17 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

> > I'm still unsure how FDs coming from a host application can be
> > converted to resource objects (and then UUIDs so they can be passed
> > to the ipc_connection) if they've not been previously created/passed
> > by the guest though.  
> 
> Depends on the kind of fd I think.  For unix sockets or virtio-fs files
> it should be easy.  dma-bufs or sysv shmem would be more tricky because
> we have to map them into the guest address space (if we want support
> that).  Not impossible though, we could use the new shared memory
> support for that.

I was more worried about the complexity an import_resource() API would
put on the host proxy: it will have to know which subsystem each of the
resources/FDs it tries to pass to the virtio-ipc socket should be
attached to, and none of those resources have actually been created by
the proxy itself. That implies having a way to get that information from
a FD (is it a dmabuf FD, a unix socket fd, ... and depending on the kind
of FD, which device/subsystem is in charge of this FD, for instance, for
dmabufs, you might need to know who allocated the buffer).



---------------------------------------------------------------------
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 12:24 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 [this message]
2020-02-27  4:20   ` David Stevens
2020-02-27  9:09     ` Boris Brezillon
     [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=20200227132425.1138be49@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.