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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox