All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Yang <lfy@google.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Roman Kiryanov <rkir@google.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	virtio-dev@lists.oasis-open.org
Subject: Re: [virtio-dev] Memory sharing device
Date: Wed, 20 Feb 2019 07:31:53 -0800	[thread overview]
Message-ID: <CAEkmjvVcCYYk_ssmU+F19qMbgMmZquhMqmfhV6pwtBfeBEjqJA@mail.gmail.com> (raw)
In-Reply-To: <20190220065152.44xv26wjtopkdnu2@sirius.home.kraxel.org>

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

On Tue, Feb 19, 2019 at 10:52 PM Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
>
> > However, dma-buf seems to require either a Linux kernel or a Linux host.
>
> Sure.  They allow passing buffers from one linux driver to another
> without copying the data.
>
> > Dma-bufs aren't also 1:1 with Vulkan host visible memory pointers,
> > or v4l2 codec buffers, or ffmpeg codec buffers, etc.
>
> Some v4l2 drivers have dma-buf support, so you can pass buffers from
> v4l2 to (for example) gpu drivers that way.
>
> > The proposed device would be able to expose memory for direct access in a
> > way that
> > does not couple to dma-buf which is highly desirable for our use case.
> > Using the ping/event messages, even win32 handles and general opaque fds
> > can be passed from host to guest and back.
> >
> > You can think of the proposed device as a 'virtio-dmabuf' that
> > tries to expose shareable memory in a way that disregards implementation
> > details of
> > guest and host kernels.
>
> That would probably look alot like virtio-gpu with only the resource
> handling.  virtio-gpu fundamentally are just buffers.
>
>
This plus new transport makes me wonder if we can have something like a
transport/device pair
where the transport makes it easy to work directly off host memory pci bar,
and the device is virtio-gpu except really just buffers.
We'd really like to go for something like this.

Also virtio-dmabuf would be a pretty bad name.  dma-bufs are not a
> virtio concept, they are a linux concept.  They can be used by linux
> guests, to pass buffers from/to virtio-gpu (note: I'm still busy adding
> driver support for that).  They can be used by linux hosts, to pass
> buffers (with udmabuf help) from qemu to other processes/devices
> (details are still to be hashed out).
>
>
Got it, that sounds pretty interesting.


> Non-linux systems obviously need something else for the job.  The
> guest/host implementation details don't affect the virtio-gpu specs
> though.


While we're talking about this: what is your plan for virtio-gpu
implementations for non-Linux guests/hosts?


>
>
cheers,
>   Gerd
>
>

[-- Attachment #2: Type: text/html, Size: 3301 bytes --]

  reply	other threads:[~2019-02-20 15:32 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-01 20:34 [virtio-dev] Memory sharing device Roman Kiryanov
2019-02-04  5:40 ` Stefan Hajnoczi
2019-02-04 10:13   ` Gerd Hoffmann
2019-02-04 10:18     ` Roman Kiryanov
2019-02-05  7:42     ` Roman Kiryanov
2019-02-05 10:04       ` Dr. David Alan Gilbert
2019-02-05 15:17         ` Frank Yang
2019-02-05 15:21           ` Frank Yang
2019-02-05 21:06         ` Roman Kiryanov
2019-02-06  7:03           ` Gerd Hoffmann
2019-02-06 15:09             ` Frank Yang
2019-02-06 15:11               ` Frank Yang
2019-02-08  7:57               ` Stefan Hajnoczi
2019-02-08 14:46                 ` Frank Yang
2019-02-06 20:14           ` Dr. David Alan Gilbert
2019-02-06 20:27             ` Frank Yang
2019-02-07 12:10               ` Cornelia Huck
2019-02-11 14:49       ` Michael S. Tsirkin
2019-02-11 15:14         ` Frank Yang
2019-02-11 15:25           ` Frank Yang
2019-02-12 13:01             ` Michael S. Tsirkin
2019-02-12 13:16             ` Dr. David Alan Gilbert
2019-02-12 13:27               ` Michael S. Tsirkin
2019-02-12 16:17                 ` Frank Yang
2019-02-19  7:17                   ` Gerd Hoffmann
2019-02-19 15:59                     ` Frank Yang
2019-02-20  6:51                       ` Gerd Hoffmann
2019-02-20 15:31                         ` Frank Yang [this message]
2019-02-21  6:55                           ` Gerd Hoffmann
2019-02-19  7:12             ` Gerd Hoffmann
2019-02-19 16:02               ` Frank Yang
2019-02-20  7:02                 ` Gerd Hoffmann
2019-02-20 15:32                   ` Frank Yang
2019-02-21  7:29                     ` Gerd Hoffmann
2019-02-21  9:24                       ` Dr. David Alan Gilbert
2019-02-21  9:59                         ` Gerd Hoffmann
2019-02-21 10:03                           ` Dr. David Alan Gilbert
2019-02-22  6:15                           ` Michael S. Tsirkin
2019-02-22  6:42                             ` Gerd Hoffmann
2019-02-11 16:57           ` Michael S. Tsirkin
2019-02-12  8:27         ` Roman Kiryanov
2019-02-12 11:25           ` Dr. David Alan Gilbert
2019-02-12 13:47             ` Cornelia Huck
2019-02-12 14:03               ` Michael S. Tsirkin
2019-02-12 15:56                 ` Frank Yang
2019-02-12 16:46                   ` Dr. David Alan Gilbert
2019-02-12 17:20                     ` Frank Yang
2019-02-12 17:26                       ` Frank Yang
2019-02-12 19:06                         ` Michael S. Tsirkin
2019-02-13  2:50                           ` Frank Yang
2019-02-13  4:02                             ` Michael S. Tsirkin
2019-02-13  4:19                               ` Michael S. Tsirkin
2019-02-13  4:59                                 ` Frank Yang
2019-02-13 18:18                                   ` Frank Yang
2019-02-14  7:15                                     ` Frank Yang
2019-02-22 22:05                                       ` Michael S. Tsirkin
2019-02-24 21:19                                         ` Frank Yang
2019-02-13  4:59                               ` Frank Yang
2019-02-19  7:54                       ` Gerd Hoffmann
2019-02-19 15:54                         ` Frank Yang
2019-02-20  3:46                           ` Michael S. Tsirkin
2019-02-20 15:24                             ` Frank Yang
2019-02-20 19:29                               ` Michael S. Tsirkin
2019-02-20  6:25                           ` Gerd Hoffmann
2019-02-20 15:30                             ` Frank Yang
2019-02-20 15:35                               ` Frank Yang
2019-02-21  6:44                               ` Gerd Hoffmann
2019-02-12 18:22                   ` Michael S. Tsirkin
2019-02-12 19:01                     ` Frank Yang
2019-02-12 19:15                       ` Michael S. Tsirkin
2019-02-12 20:15                         ` Frank Yang
2019-02-12 13:00           ` Michael S. Tsirkin

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=CAEkmjvVcCYYk_ssmU+F19qMbgMmZquhMqmfhV6pwtBfeBEjqJA@mail.gmail.com \
    --to=lfy@google.com \
    --cc=dgilbert@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=mst@redhat.com \
    --cc=rkir@google.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-dev@lists.oasis-open.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.