Message-ID: <ZeZoPAJw2Ip_Lgch@mail-itl>
Date: Tue, 5 Mar 2024 01:33:00 +0100
From: Marek Marczykowski-Górecki <marmarek@...isiblethingslab.com>
To: Demi Marie Obenour <demi@...isiblethingslab.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, linux-usb@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: usbip doesn't work with userspace code that accesses USB devices

On Mon, Mar 04, 2024 at 07:06:08PM -0500, Demi Marie Obenour wrote:
> On Tue, Mar 05, 2024 at 12:52:22AM +0100, Marek Marczykowski-Górecki wrote:
> > On Mon, Mar 04, 2024 at 11:46:04PM +0100, Marek Marczykowski-Górecki wrote:
> > > On Mon, Mar 04, 2024 at 09:04:00PM +0000, Greg KH wrote:
> > > > On Mon, Mar 04, 2024 at 03:01:51PM -0500, Demi Marie Obenour wrote:
> > > > > Qubes OS users are reporting that MTP doesn't work with USB passthrough.
> > > > > Fastboot (used for flashing a custom OS to an Android device) also
> > > > > doesn't work.  Kernel-mode drivers, such as Bluetooth and USB storage,
> > > > > seem to usually work as expected.  Since MTP and fastboot are both
> > > > > implemented in userspace, it appears that there is some problem with the
> > > > > interaction of usbip, our USB proxy (which is based on USBIP), and
> > > > > userspace programs that interact with USB devices directly.
> > > > > 
> > > > > The bug report can be found at [1] and the source code for the USB proxy
> > > > > can be found at [2].  The script used on the sending side (the one with
> > > > > the physical USB controller) is at [3] and the script used by the
> > > > > receiving side (the one the device is attached to) is at [4].  All of
> > > > > these links are for the current version as of this email being sent, so
> > > > > that anyone looking at this email in the future doesn't get confused.
> > > > > 
> > > > > Is this a bug in usbip, or is this due to usbip being used incorrectly?
> > > > 
> > > > I'm amazed that usbip works with usbfs at all, I didn't think that was a
> > > > thing.
> > > > 
> > > > If you have a reproducer, or some error messages somewhere, that might
> > > > be the easiest way forward.  In reading the bug report, it looks like
> > > > the "bridge" you all made can't handle the device disconnecting itself
> > > > properly?  But that's just a guess, could be anything.
> > > 
> > > Device disconnecting itself indeed is an issue (our proxy doesn't
> > > automatically reconnect it, at least not yet). But that's definitely not
> > > the only issue, things break also when disconnect is not involved.
> > > 
> > > Terminology:
> > > 1. sys-usb - a VM where USB controller (a PCI device) lives; here
> > > usbip-host is attached to the device
> > > 2. testvm - target VM where usbip is connected; here vhci-hcd is used
> > > 3. qvm-usb - tool that connects the above two (equivalent of
> > > userspace part of standard usbip)
> > > 
> > > Specific steps:
> > > 1. Connect android phone - at this point it's only in sys-usb
> > > 2. Switch its mode to file transfer - observe reconnect in sys-usb
> > > 3. Use qvm-usb to attach it to the testvm
> > > 4. Call jmtpfs -d /mnt in testvm
> > 
> > Or maybe reset or something is involved here too?
> > 
> > After using qvm-usb to attach _and detach_ the device, it stays bound to
> > usbip-host driver (that's intentional). But then, even after re-binding
> > back to the "usb" driver, jmtpfs called in sys-usb directly fails the
> > same way, including failure to reset.
> > 
> > In fact, even without usbip involved at all, jmtpfs directly in sys-usb
> > works only once. The second attempt (without either physically reconnecting
> > the phone, or changing its more to "no data transfer" and back to "file
> > transfer") fails the same way. After terminating the first instance, I
> > see just this logged:
> > 
> >     [921332.525210] usb 2-1: reset high-speed USB device number 22 using xhci_hcd
> 
> What happens if the device is not bound to _any_ driver in sys-usb?  For
> instance, does the problem go away if the only USB-related drivers in
> sys-usb are xhci-pci, usbip-host, and their dependencies?  If not, what
> about if sys-usb's kernel has no other USB-related drivers included at
> all?

I don't think I can get rid of the "usb" driver, and that's what binds to
the device. There is no driver bound to the first interface of the
device (2-1:1.0) at all.

> Also, if you have not done so already, could you try uninstalling gvfs
> from sys-usb's template?  gvfs might be interacting with the device.
> Using a -minimal template might help.

I highly doubt it would change anything.

> > Since both problematic cases involve Android, maybe the actual issue is
> > somewhere in Android instead of usbip? But then, fastboot could be a
> > completely different issue, likely related to reconnection (this one I
> > haven't tried to reproduce, and can't find much details in our issues
> > tracker).
> > On the other hand, USB tethering works just fine, so at least some
> > Android functions do work with usbip (but then, it's a kernel driver,
> > not usbfs).
> > Could be also an issue with just MTP implementation on either side of
> > the connection (I did tried also gvfs instead of jmtpfs with similar
> > result, but they likely use the same implementation). Since that's
> > Android, the device side is Linux too, but I don't know how MTP is
> > implemented there (I don't see MTP gadget function in upstream Linux).
> 
> I suspect MTP is implemented in userspace somewhere in AOSP.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists