Hi all,
Sorry for the formatting issues.
I'd like to join the discussion and share my perspective.
Greg's main concern is: "Why is this needed at all?" Let me explain.
First of all, our primary focus is embedded systems, including the
automotive
industry, particularly infotainment systems. In this area, the easiest
way to
provide USB access to a GVM is to pass the USB device directly through
to the
guest. This is even simpler than usb-ip, since we can rely on the
standard Linux
USB driver.
And it works well until we need more flexibility, such as:
- Sharing different USB devices connected to the same USB host among
multiple
VMs (for instance, assigning one USB stick to the AGL GVM, another to the
Android GVM, and a sound card to the PVM).
- Sharing multiple USB gadget functions from several VMs through the
same USB
gadget port (for instance, providing ADB connectivity to all VMs,
including
the PVM and both GVMs).
Once this level of flexibility is required, simple passthrough is no longer
sufficient, and we have to rely on USB sharing mechanisms.
And this brings us to Greg's main concern: Why not simply use usb-ip to
share
USB devices between the PVM and GVMs? Why introduce an entirely new
transport
for USB virtualization instead of relying on existing solutions?
There are several reasons for this.
First, we aim to support not only Linux-based hosts. The host could be
running
QNX or even a bare-metal (no-OS) environment, where usb-ip and usbfs are not
available. Igor has already explained this point. However, as you rightly
pointed out:
> Or more realisticly, why should _I_ care about anything other than
Linux? :)
It seems, you are right: why you should pay efforts reviewing our
patches, while
nonone excpet us will be able to utilize this for non-Linux based
workpaces. In
reality, the opposite is true: if VirtIO USB becomes a standard part of the
open-source Linux kernel, USB virtualization will become
hypervisor-agnostic.
For end users who rely on open-source or commercial hypervisors, it will not
matter which hypervisor is running under the hood (for example, QNX or
QEMU).
They will be able to use the open-source Linux kernel out of the box,
without
any modifications. If they later decide to migrate to a different hypervisor
that supports the standard, the transition will require little to no effort.
Therefore, the Linux community should, in principle, be interested in
supporting
this effort.
Furthmore, this is not only about host OS, this also about guests. Let's
imagine
you want to run QNX or VxWorks image under qemu on Linux Host. Both GVM OS
supports OASIS Virtio Standard, but does not support usb-ip. Therefore,
we would
like to introduce a common approach that works across all operating systems.
And we also plan to add virtio-usb support to QEMU as well. This
approach will
be available to the broader community as well, not just as a proprietary
solution.
The second important reason is that one of the key virtio-usb features
we need,
and which partially motivated this work, is support for a dual-role USB
controller for Apple CarPlay. usb-ip cannot provide this because it
lacks OTG
support.
Third, performance is another reason for introducing a new solution.
Igor has
already partially explained this point. Existing solutions such as
usb-ip rely
on sockets and therefore introduce additional overhead. This becomes
particularly important in resource-constrained embedded systems. With
our own
implementation, we can avoid this overhead.
Fourth, as Igor has already mentioned, usb-ip and usbfs do not work out
of the
box. They still require additional configuration on the GVM side to function
properly. Yes, this is standard Linux administration, but it still requires
additional configuration and maintenance effort.. In contrast, a vanilla
Linux
kernel with VirtIO USB support will boot and operate as is, requiring zero
additional effort.
Last but not least, let's be honest: usb-ip is not really about
virtualization.
Its primary goal is to share USB devices over a network. This is a perfectly
valid solution, but it serves a different purpose than virtio-usb. By
the same
reasoning, one could ask: "Why do we need virtio-gpu when we can simply
use RDP
over IP?". In other words, this is not about inventing a brand-new
transport. It
is about defining and standardizing an existing approach as an open industry
standard.
Best Regards,
Vasilii
On 9/29/2026 6:01 PM, Greg Kroah-Hartman wrote:
On Tue, Sep 29, 2026 at 05:47:30AM -0400, Michael S. Tsirkin wrote:
On Mon, Sep 28, 2026 at 03:55:38PM +0200, Igor Skalkin wrote:
[RFC PATCH v2] virtio-usb: Add initial virtio-usb specification
Igor Skalkin <[email protected]>
[email protected]
https://lore.kernel.org/virtio-comment/[email protected]/
This driver has been tested end-to-end against our own userspace
virtio-usb device implementation (host-side backend) in two setups:
Where is that code and why isn't it part of this submission?
The backend we used for the testing described above is an internal
implementation that we're not releasing as part of this submission - it
integrates with some systems that aren't ready to be public. We
recognize that limits independent verification of our specific test
results, and we don't think that's an ideal situation.
Supporting vhost-user with a backend doing pass-through shouldn't be too hard.
Wait, if all you want is adb to work, why not just use it in network
mode? That should work find across a virtual machine, right?
thanks,
greg k-h
