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.
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.
>>>> [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.
>
> Then we can't even review this at all, sorry, you all know better than
> that.
We're considering publishing a virtio-usb test device for QEMU to make
independent testing easier.>
>>>> 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.
>
OK, will change commit message. In this commit I just add some SS
specific details to EP0 processing and fix SS issues.
> 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?
>
Answered both points above (usb-ip/usbfs, and the backend visibility
question) - happy to go deeper on either if those answers don't address
your concern.
> thanks,
>
> greg k-h
Thanks,
Igor
