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
