All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Frank Yang <lfy@google.com>,
	"Michael S. Tsirkin" <mst@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: Thu, 21 Feb 2019 09:24:55 +0000	[thread overview]
Message-ID: <20190221092455.GB2605@work-vm> (raw)
In-Reply-To: <20190221072950.tcii5np5dsk4wvyd@sirius.home.kraxel.org>

* Gerd Hoffmann (kraxel@redhat.com) wrote:
>   Hi,
> 
> > > For communication between guest processes within the same VM I don't
> > > really see a need to involve the hypervisor ...
> > >
> > Right, once the host memory is set up we can rely on purely guest side stuff
> > map sub-regions of it.
> 
> Or just use guest ram ...
> 
> > > > Yes, also, other devices of the same VM.
> > >
> > > So why involve the hypervisor here?  The guest can handle that on its
> > > own.  Passing an image data buffer from the usb webcam to the intel gpu
> > > for display (on bare metal) isn't fundamentally different from passing a
> > > buffer from virtio-camera to virtio-gpu (in a VM).  Linux guests will
> > > use dma-bufs for that, other OSes probably something else.
> > 
> > That's true that it can be handled purely in the guest layers,
> > if there is an existing interface in the guest
> > to pass the proposed host memory id's / offsets / sizes
> > between them.
> 
> Note:  I think using a pci memory bar (aka host memory mapped into the
> guest) as backing storage for dma-bufs isn't going to work.

(Not knowing dma-bufs) but could you explain why?
Note in my spec the pci-bar isn't necessarily one chunk of host memory;
it's a chunk of host VMA into which multiple mmaps go.

Dave

> > However, for the proposed host memory sharing spec,
> > would there be a standard way to share the host memory across
> > different virtio devices without relying on Linux dmabufs?
> 
> I think with the current draft for each device (virtio-fs, virtio-gpu,
> ...) has its own device-specific memory, and there is no mechanism to
> exchange buffers between devices.
> 
> Stefan?
> 
> I'm also not convinced that explicitly avoiding dmabufs is a good idea
> here.  That would put virtio into its own universe and sharing buffers
> with non-virtio devices will not work.  Think about a intel vgpu as
> display device, or a usb camera attached to the guest using usb
> pass-through.
> 
> Experience shows that using virtualization-specific features /
> optimizations / short-cuts often turns out to have drawbacks in the long
> run, even if it looked like a good idea initially.  Just look at the
> mess we had with virtio-pci dma after iommu emulation landed in qemu.
> And this is only one example, we have more of this ...
> 
> cheers,
>   Gerd
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

---------------------------------------------------------------------
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:[~2019-02-21  9:25 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
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 [this message]
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=20190221092455.GB2605@work-vm \
    --to=dgilbert@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lfy@google.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.