Increase or remove limit on number of devices that can be attached to a single qube via the USB proxy (current limit: 8)

[tlaurion]

Qubes OS version R4.0

Affected component(s) or functionality usb-proxy

Brief summary Trying to attach more then 8 usb-devices to an AppVM doesn't seem possible.

How Reproducible Attaching more then 8 USB drives triggers an error.

To Reproduce

Attach a ninth USB drive to an AppVM.

Expected behavior No limit of USB devices should be enforced.

Actual behavior Triggers an error

Screenshots

Additional context

AppVM based template: Debian-10

• qubes-input-proxy-receiver-dbgsym/unknown 1.0.20-1+deb10u1 amd64
• qubes-input-proxy-receiver/unknown 1.0.20-1+deb10u1 amd64
• qubes-input-proxy-sender-dbgsym/unknown 1.0.20-1+deb10u1 amd64
• qubes-input-proxy-sender/unknown,now 1.0.20-1+deb10u1 amd64 [installed,automatic]

Solutions you've tried

Relevant documentation you've consulted

Related, non-duplicate issues

[marmarek]

What is a real world use case where you need more than 8 USB devices attached to a single VM? This is a build-time limit of USB IP driver (CONFIG_USBIP_VHCI_HC_PORTS), which defaults to 8. We can increase it, but it will make the driver use (slightly) more memory for everybody, not only when assigning more devices.

[tlaurion]

@marmarek Well, in my personal use case, I use an AppVM to prepare sdcards, where a script detect the insertion of a new /dev/sd* usb device and when assigned, just provision it with information related to a specific order, waiting for new device to be connected and detected.

The behavior changed recently (cannot tell when), since my USB3 hub (10 ports) cannot be used for more then 8 usb drives preparation at a time. sys-usb sees the device, but cannot dispatch them to the specific AppVM with the usb proxy.

My work around with this use case, if I understand well, would be to have sys-usb do the job directly?

[marmarek]

The behavior changed recently (cannot tell when)

No, it was this way at least since 2014 (haven't checked earlier).

My work around with this use case, if I understand well, would be to have sys-usb do the job directly?

Yes, that will work. Alternatively you can use qvm-block instead (AFAIR the limit is higher there). Or simply connect at most 8 devices at once.

[marmarek]

Note the limit is 8 separately for USB2 and USB3. Maybe that's what worked for you before - some devices were USB2?

[andrewdavidwong]

If I understand correctly, it has been determined that this behavior is not a bug, so I'm closing this as "not an issue." If you believe this is a mistake, please leave a comment, and we'll be happy to take another look. Thank you.

[tlaurion]

So basically, implied workaround is to duplicate sys-usb pci devices under devices tabs for AppVMs requiring more then 8 usb devices, so that the required AppVM has exclusive access to desired USB controllers. And they can have exclusive access directly to USB devices, since usb-proxy is limited to a maximum of 8 passed devices through usb proxy (device assignation from sys-usb to desired AppVM) prior of action. That AppVM will need to be booted up when sys-usb is shut down.

Conclusion: QubesOS won't change usb proxy maximal USB devices higher then 8 usb devives since it would involve higher memory consumption from the proxy. If having more then 8 USB devices passed from sys-usb to AppVM is required, manually assign USB Decives uder QubesOS configuration device to have needed sys-usb pci controllers to your AppVM. And shut down sys-usb prior of firing up your desired AppVM.

@andrewdavidwong : That won't be supported by QubesOS (won't fix) tag should be applied.

[DemiMarie]

CONFIG_USBIP_VHCI_HC_PORTS seems rather silly. Why can’t that data structure be allocated on the kernel heap?

In any case, I would support bumping it to 64 or thereabouts.

[tlaurion]

Note the limit is 8 separately for USB2 and USB3. Maybe that's what worked for you before - some devices were USB2?

Possible that I used x230 yellow port (USB2) instead of blue ports (USB3), while doubtful.

[marmarek]

CONFIG_USBIP_VHCI_HC_PORTS seems rather silly. Why can’t that data structure be allocated on the kernel heap?

Feel free to suggest that to the USB IP maintainers...

Anyway, if I'm not mistaken, we're talking about 432 bytes per port. We can easily make that 64.

BTW I wonder how much sense makes using such hubs performance-wise. After all, all those devices are connected to a single USB3.0 port, which - with 10 devices - gives you ~62MB/s per device top (at USB level, much less on the block transfer level because of the USB overhead). May be still reasonable for slower or small storage devices, but not really for fast ones.

[marmarek]

Anyway, if I'm not mistaken, we're talking about 432 bytes per port. We can easily make that 64.

Some more, as there are at least sysfs-visible structures. Still, I don't think more than 1kb per port.

[tlaurion]

@marmarek agreed that speed is lowered a bit (sdcard are not that fast) but gained by total unattended time gained by doing a lot at the same time.

[andrewdavidwong]

@andrewdavidwong : That won't be supported by QubesOS (won't fix) tag should be applied.

No, if the Qubes developers determine that it's not a bug, then won't fix wouldn't apply, because there would be no bug to be fixed (or not to be fixed).

However, it now looks like this determination has changed. Difficult to tell whether it's now an enhancement.

[3hhh]

Btw there's also that issue of ~20 mountable devices per VM (/dev/xvdc --> /dev/xvdz). I'm usually at 19 or so. ^^

[github-actions[bot]]

This issue is being closed because:

• This issue is on the "Release 4.0 updates" milestone.
• Qubes OS 4.0 reached EOL (end-of-life) over one year ago.
• There has not been any activity on this issue in over one year.

If anyone believes that this issue should be reopened and reassigned to an active milestone, please leave a brief comment. (For example, if a bug still affects Qubes OS 4.1, then the comment "Affects 4.1" will suffice.)

[benma]

I also want to attach more than 8 devices. What are the steps to take to suggest an increase here? Currently I am in need of 10-15.

[tlaurion]

Thank you @andrewdavidwong for replopening this. Provisioning usb thumb drives is still needed from OEMs AFAIK.

[marmarek]

@tlaurion for usb sticks, qvm-block might be a better approach, I think the limit there is higher.

[benma]

Can we bump the limit please to 10-15? What's the process to make this happen? I still need this, and manually messing with pci controllers and similar is impractical.