Hi,
> As another example, consider camera / video playback. I've heard that the
> way to approach this
> is to build v4l2 and build a virtio-v4l2 layer underneath.
That would be one option, yes. virtio-v4l2 is a pretty bad name though,
I'd name it virtio-camera or virtio-media (if you want both capture and
playback) and you don't have to mimic the v4l2 api at virtio level.
I think a big thing that's different about our context is that,
there are issues when running on non-Linux hosts, non-QEMU hypervisors or non-Linux kernels that isn't commonly encountered
in the virtio community.
I agree that using v4l2 API itself would bake in all sorts of design decisions
that might not be the best idea for a given host-side codec or camera library.
Â
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 and a message to notify either guest or host
that there is something interesting to do with the host memory,
that we'd like to capture with the proposed spec.
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.
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. 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.
We'd want to benefit from being able to run reliably on hosts other than Linux (which makes Unix sockets riskier),
with RAM being the underlying buffer storage.
Â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.
Â
> However, this would mean either assuming v4l2 on host which is not
> portable to non-Linux, or requiring additional translation layers
> between v4l2 in the guest and $library on the host.
Well, sure, you need to wire up the host side somehow anyway. Emulate
something virtual, feed the guest camera with image data from the host
camera, ...
Right, but we also don't want to couple the implementations together.
As specified in the example, the implementation of how the guest camera and host camera work together
is defined in areas away from the guest kernel.
As long as there are no conflicting device ID's in the configuration space,
we can also tell when a particular usage is supported.
> With the proposed spec, a more general 'codec' device can be
> implemented, tested on actual programs on multiple guests/hosts
> easily, and then, if it makes sense, "promoted" to a new
> "virtio-codec" device type.
I fail to see how a more general device avoids host-specific code (to
talk to the host camera, for example).
Â
Agreed, no, it doesn't; but it facilitates the possibility of the same host-specific code
to be defined in a different library from QEMU or whatever VMM is being used.
To update driver/device functionality, ideally we want to ship two small shared libraries,
one to guest userspace and one to plug in to the host VMM.
Â
cheers,
 Gerd
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org