Re: [PATCH 0/8] virtio-usb: add dual-role virtio USB driver

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Mon, Sep 28, 2026 at 05:56:22PM +0200, Igor Skalkin wrote:
> 
> 
> On 9/28/2026 4:44 PM, Greg Kroah-Hartman wrote:
> > On Mon, Sep 28, 2026 at 03:55:38PM +0200, Igor Skalkin wrote:
> >>
> >>
> >> On 9/25/2026 7:17 AM, Greg Kroah-Hartman wrote:
> >>> On Thu, Sep 24, 2026 at 06:08:59PM +0200, Igor Skalkin wrote:
> >>>> This series adds a new virtio-usb driver: a dual-role virtio device
> >>>> capable of acting as a USB host controller, a USB device controller,
> >>>> or both simultaneously with runtime role switching between the two
> >>>> (USB OTG-style role switching) on ports that support it.
> >>>>
> >>>> The corresponding virtio-usb device specification has been posted to
> >>>> virtio-comment for review. This series matches the v2 revision of
> >>>> that spec, which reconciles a small number of protocol details
> >>>> (per-role virtqueue presentation, host-role vp_idx for hub/multi-VP
> >>>> support, and the device-role BIND/UNBIND event split) that were
> >>>> clarified while integrating and testing this driver against the
> >>>> spec:
> >>>
> >>> Why do we need this at all when we have other ways of doing usb devices
> >>> through virtio?
> >>>
> >>> Why is a USB virtio spec needed at all, who is going to use it?
> >>>
> >>>
> >> For device classes that already have a virtio equivalent (storage, HID,
> >> video, audio) there's no need for virtio-usb: we can use
> >> virtio-blk/virtio-input/virtio-video/virtio-snd directly.
> >> What virtio-usb actually addresses is different: protocols that are
> >> about raw USB semantics itself, not about any particular device class.
> >> Two concrete cases we care about. ADB (Android Debug Bridge), a specific
> >> USB interface/vendor-class protocol used throughout Android development
> >> and debugging, with no meaningful way to express it as a block or HID
> >> device. And Android Auto (AOA) / Apple CarPlay, USB-level
> >> control-transfer and vendor-negotiation protocols used when a phone is
> >> plugged into an automotive head unit.
> >> Our motivating use case is automotive cockpit virtualization: a physical
> >> USB port where a phone is plugged in needs to be handed to a guest VM
> >> running the head-unit stack, and that guest needs to run one of these
> >> USB-native protocols. The existing software on both sides already speaks
> >> raw USB and works unmodified if it sees a real-looking USB device.
> >> virtio-usb lets that keep working, instead of needing a new bespoke
> >> virtio spec for every such protocol as new USB-based ecosystems show up.
> > 
> > So you just want "raw" usb, then why not use usb-ip?  Isn't that what
> > it's there for?  Or just mount usbfs and expose that to the host as
> > that's what adb is using already, right?
> > 
> usb-ip's host and guest sides are both Linux-specific - in some of our
> target deployments the host OS isn't Linux at all (e.g. QNX), so there's
> no usb-ip host-side implementation to use in the first place.
> virtio-usb's backend only needs to speak the virtio transport, which is
> host-OS-agnostic.

But you are making a brand new virtio transport, which will have to be
written for all OSes.  usb-ip already works on other operating systems
today.  Same for usbfs through libusb.

> Separately, usb-ip requires explicit manual configuration on both sides
> for every device. Its own checklist also calls for disabling SELinux and
> opening a TCP port. We're trying to avoid that operational overhead
> (ideally - fully virtualized vanilla Android as a guest).
> usbfs is a different layer - it lets a local process talk to a
> locally-attached device (how the ADB host daemon works today), but
> doesn't address getting the USB device into the guest in the first place.
> And usbfs is Linux-specific too.

No, see libusb, it abstracts that away.

And really, why do you want to do anything other than Linux.  Or more
realisticly, why should _I_ care about anything other than Linux?  :)

Again, mount usbfs and away you go, libusb is your friend :)

thanks,

greg k-h