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