On Wed, Feb 20, 2019 at 7:30 AM Frank Yang <> wrote:
On Tue, Feb 19, 2019 at 10:25 PM Gerd Hoffmann <> wrote:
 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.
Â
True, thanks for pointing it out.
Although, I'd still think it is still a bit nicer to do it via a host memory buffer,
because it'd be outside of guest ram;
we wouldn't have to interface as tightly with the kernel in terms of not interfering with
other guest RAM usages,
such as equivalents of dma_alloc_coherent with the limitation on CMA and all.
> 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.
Â
Yeah, that's (almost?) exactly what we want to do / we're doing already pretty much
with the memory sharing scheme we're using currently.
Defining it as a transport would also require definition of another virtio device type
that the userspace drivers talk to, right?
As a transport/device pair, would it break down as, the transport ends up restricting what kinds of addresses can be referred to in the ring messages (in the pci memory bar),
then the device provides the userspace drivers with
implementation of mmap() + memory allocation/sharing ops and notification?
Â
> 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.
We also have a similar feature flag system,
but yeah it would be great to use the capabilities/flags
to their fullest extent here.
Â
> 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.
Â
Yeah for performance considerations, sockets seem to be fine.
(for low bandwidth devices that is, just to be clear)Â
It's just that I've also got concerns on how well sockets work on non-Linux.
> > 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.
Â
That's pretty interesting; from a brief glance at xhci, it looks like what you're proposing
is that since there usb passthrough already with xhci,
and xhci has something that looks like a virtqueue,
perhaps we can create our own USB driver on the host,
then pass it through.
It does make things more inconvenient for users though since they would have to install
usb drivers out of nowhere. Wonder if a usb forwarder virtual device exists that can talk to some shared library on the host for the xhci queue, though that might be considered an unsafe plugin.
Â
cheers,
 Gerd
