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

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

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?

> >>   [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.

Then we can't even review this at all, sorry, you all know better than
that.

> >>   4-5: USB OTG-style role query and role-switching support.
> > 
> > There's a reason OTG isn't used anymore by devices, how have you
> > addressed those problems here?  And why duplicate the failures of the
> > past?
> > 
> We're not implementing ID-pin detection, HNP, or SRP - none of that.
> "OTG" here is just a reused name for something much simpler: an explicit
> role-switch command exposed to the guest via sysfs. Device-to-host is
> driver-initiated (guest writes to that sysfs entry); host-to-device is
> host-initiated (the host switches on its own and notifies the guest).
> Either direction is always granted - no negotiation step to get wrong.
> Happy to rename the OTG-tagged commands/constants if the naming is
> causing confusion.

"OTG" has a _VERY_ specific definition in the USB world, don't attempt
to re-define it please.  That way lies madness...

> >>   6:   endpoint-lifecycle robustness rework (async split-phase state
> >>        machine, replacing an earlier out-of-tree gadget.nonatomic
> >>        patch that didn't pass upstream review).
> >>   7:   SuperSpeed device-role support.
> > 
> > Why should speed settings matter to a virtual connection?
> >
> Because the kernel APIs we're implementing on top of are inherently
> speed-typed, not because of any real electrical/physical constraint.
> usb_hcd (host role) and the USB Gadget API (device role) both bake speed
> into their core design - it drives enumeration, bandwidth scheduling,
> and descriptor selection (e.g. SuperSpeed companion descriptors) in the
> USB core and in gadget function drivers. dummy_hcd is a good precedent:
> it's also a purely virtual host controller with no real signaling, and
> it still has to declare and support different speed configurations,
> because the framework requires it. We're in the same position -
> unmodified guest USB class drivers and gadget function drivers depend on
> accurate speed information regardless of what's actually behind the
> interface.

This is a virtual connection, speed means nothing here other than some
descriptor stuff in a few places.

Again, try using the existing code, usb-ip or usbfs, don't invent
something new, especially when it's not even visable to anyone.  Would
you want to attempt to review something like this in that situation?

thanks,

greg k-h