Linux USB
 help / color / mirror / Atom feed
From: Vasilii Ianikeev <vasilii.ianikeev@oss.qualcomm.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: Igor Skalkin <igor.skalkin@oss.qualcomm.com>,
	Jason Wang <jasowangio@gmail.com>,
	virtualization@lists.linux.dev, linux-usb@vger.kernel.org,
	Aiswarya Cyriac <aiswarya.cyriac@oss.qualcomm.com>,
	Anton Yakovlev <anton.yakovlev@oss.qualcomm.com>,
	Trilok Soni <trilok.soni@oss.qualcomm.com>
Subject: Re: [PATCH 0/8] virtio-usb: add dual-role virtio USB driver
Date: Tue, 29 Sep 2026 21:58:23 +0200	[thread overview]
Message-ID: <9161039f-c68e-4f86-8f8d-2339ddc4b128@oss.qualcomm.com> (raw)
In-Reply-To: <2026092928-borough-tried-1ea7@gregkh>

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 <igor.skalkin@oss.qualcomm.com>
>>>>>    virtio-comment@lists.linux.dev
>>>>>    https://lore.kernel.org/virtio-comment/20260924154007.143927-1-igor.skalkin@oss.qualcomm.com/
>>>>>
>>>>> 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

      parent reply	other threads:[~2026-09-29 19:58 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 16:08 [PATCH 0/8] virtio-usb: add dual-role virtio USB driver Igor Skalkin
2026-09-24 16:09 ` [PATCH 1/8] virtio-usb: add protocol header and skeleton dual-role driver Igor Skalkin
2026-09-25  5:14   ` Greg Kroah-Hartman
2026-09-28 14:19     ` Igor Skalkin
2026-09-25  5:21   ` Greg Kroah-Hartman
2026-09-28 14:14     ` Igor Skalkin
2026-09-24 16:09 ` [PATCH 2/8] virtio-usb: add host role (USB Host Controller) support Igor Skalkin
2026-09-25  5:18   ` Greg Kroah-Hartman
2026-09-28 14:01     ` Igor Skalkin
2026-09-24 16:09 ` [PATCH 3/8] virtio-usb: add device role (USB Device " Igor Skalkin
2026-09-24 16:09 ` [PATCH 4/8] virtio-usb: add OTG role query support Igor Skalkin
2026-09-24 16:09 ` [PATCH 5/8] virtio-usb: add USB On-The-Go role-switching support Igor Skalkin
2026-09-24 16:09 ` [PATCH 6/8] virtio-usb: rework endpoint lifecycle to an async split-phase state machine Igor Skalkin
2026-09-24 16:09 ` [PATCH 7/8] virtio-usb: add SuperSpeed device-role support Igor Skalkin
2026-09-24 16:09 ` [PATCH 8/8] virtio-usb: support a guest UDC name prefix from the bind event Igor Skalkin
2026-09-25  5:17 ` [PATCH 0/8] virtio-usb: add dual-role virtio USB driver Greg Kroah-Hartman
2026-09-28 13:55   ` Igor Skalkin
2026-09-28 14:44     ` Greg Kroah-Hartman
2026-09-28 15:56       ` Igor Skalkin
2026-09-28 16:10         ` Greg Kroah-Hartman
2026-09-29  9:47     ` Michael S. Tsirkin
2026-09-29 16:01       ` Greg Kroah-Hartman
2026-09-29 19:02         ` Vasilii Ianikeev
2026-09-29 19:58         ` Vasilii Ianikeev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9161039f-c68e-4f86-8f8d-2339ddc4b128@oss.qualcomm.com \
    --to=vasilii.ianikeev@oss.qualcomm.com \
    --cc=aiswarya.cyriac@oss.qualcomm.com \
    --cc=anton.yakovlev@oss.qualcomm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=igor.skalkin@oss.qualcomm.com \
    --cc=jasowangio@gmail.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=trilok.soni@oss.qualcomm.com \
    --cc=virtualization@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox