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.
>>
>> [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.
>> 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.
>> 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.
> thanks,
>
> greg k-h
Thanks,
Igor
