Re: passing FDs across domains

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 17, 2019 at 6:31 PM Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
>
> > > > Mojo IPC. Mojo is just yet another IPC designed to work over a Unix
> > > > socket, relying on file descriptor passing (SCM_RIGHTS) for passing
> > > > various platform handles (e.g. DMA-bufs). The clients exchange
> > > > DMA-bufs with the service.
> > >
> > > Only dma-bufs?
> > >
> >
> > Mojo is just a framework that can serialize things and pass various
> > objects around. What is being passed depends on the particular
> > interface.
> >
> > For the camera use case that would be DMA-bufs and fences.
>
> Hmm, fences.  That'll be tricky too.
>
> > We also have some more general use cases where we actually pass files,
> > sockets and other objects there. They can be easily handled with a
> > userspace proxy, though. Not very efficiently, but that's not a
> > requirement for our use cases.
>
> Ok.  So you'll have a userspace proxy anyway?
>
> That pretty much removes the requirement to handle dma-bufs in
> virtio-vsock (even though that still might be the best option),
> the proxy could also use virtio-gpu or something else.
>

We have a proxy for some other IPC interfaces, like sharing guest
files with the host. It doesn't handle DMA-bufs or fences, but those
could be added. Given that, no, technically we don't need that in
virtio-vsock. It would cost us a bit of latency, but it should work
okay.

Still, we need to solve the same problem of passing buffers and fences
for other use cases that are going to be virtualized properly, like
video and crypto mentioned earlier. I believe the solution could be
reused easily in vsock.

> > > Any ideas or plans for files?
> >
> > This is a very interesting problem and also depends on the direction
> > of transfer.
> >
> > Host -> guest should be relatively easy, as reads/writes could go
> > inline, while guest side mmap could rely on the shared memory to map
> > the host file mapping into the guest, although I'm not sure how that
> > would play with the host fs/block subsystems, read aheads, write backs
> > and so on...
> >
> > Guest -> host would be more complicated. In the simplest approach one
> > could just push the data inline and expose the files locally via FUSE.
> > Not sure if any memory sharing can be reasonably implemented here, due
> > to guest side fs/block not aware of the host accessing its memory...
>
> One option could be to build on virtio-fs.  For files stored elsewhere
> fallback to inline read/write and maybe simply disallow mmap.

That's an option too.

Best regards,
Tomasz



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux