search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
532 stars 46 forks source link

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

Open tlaurion opened 3 years ago

tlaurion commented 3 years ago

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 2020-11-25-131151

Additional context

AppVM based template: Debian-10

Solutions you've tried

Relevant documentation you've consulted

Related, non-duplicate issues

marmarek commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

andrewdavidwong commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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] commented 1 year ago

This issue is being closed because:

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 commented 4 months ago

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 commented 4 months ago

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

marmarek commented 4 months ago

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

benma commented 1 month ago

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.