Re: [virtio-dev] Memory sharing device

[Gerd Hoffmann <kraxel@redhat.com>]

  Hi,

> > That might simlify pass-through of v4l2 host devices, but isn't
> > necessarily the best choice long-term.

> Right, but if we're not emulating at the v4l2 api level, then it starts
> looking a lot
> like the proposed virtio-hostmem; there's a common pattern of
> direct access to host memory

Typically camera hardware can DMA the image data to any place in memory,
including guest ram.  There is no need to expose host memory to the
guest for that.  The normal virtio workflow with guest-allocated buffers
will work just fine.

> In addition, we'd like to do things in a way
> that allows virtual drivers/devices to be defined in a manner that doesn't
> require the guest kernel to be updated.

Hmm.  I'm wondering whenever you just need a different virtio transport.
Very simliar to virtio-pci, but instead of using all guest ram (modulo
iommu quirks) as address space use a pci memory bar as address space.
virtio rings would live there, all buffers would live there, addresses
passed around would be offsets into that pci bar.  Then your userspace
driver can just mmap() that pci bar and handle (almost?) everything on
its own.  Maybe a little stub driver in the kernel is needed for ring
notifications.

> For us, maintaining and upgrading guest kernels in response to tweaks to
> virtual devices
> is much more work than modifying a userspace shared library driver that
> communicates to some virtio driver.

Well, one of the design goals of virtio is that such an upgrade is not
required.  Capabilities of device and driver are negotiated using
feature flags, which removes the need for lockstep updates of guest and
host.

> Thus far, it's suggested that socket or
> network devices
> be used for this, because they are general guest/host communication,
> but they don't have the portability or performance characteristics we want.

For high-bandwidth fully agree.

For low-bandwidth (like the sensors discussed elsewhere in the thread) I
think running some protocol (mqtt, something json-based, ...) over
virtio-serial or virtio-vsock isn't too bad.

But creating virtio-sensors makes sense too.

> > Alternatively emulate something existing, USB Video Class device for
> > example.
> 
> Using usb or faking some other transport generally also involves being
> coupled to that set of kernel code in the guest, which introduces
> complexity and overhead.  Exposing RAM can be a more flexible
> abstraction.

Well, you get guest drivers for free and all existing software will run
just fine out-of-the-box.

Which is the reason why there is no virtio-usb for example.  xhci has a
hardware design which can be emulated without much overhead, so the
performance benefit of virtio-usb over xhci would be pretty close to
zero.

cheers,
  Gerd