Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
On 2012-09-18 11:41, Hans de Goede wrote: Hi, On 09/17/2012 06:22 PM, Jan Kiszka wrote: If that does not work, add the debug parameter to the usb-redir device, set it to 4, collect logs of trying to redirect the device and send me the logs please, ie: -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4 Also be aware that usb-redir relies on chardev flowcontrol working, which it does not upstream! See for example here for the chardev flow control patch set which RHEL / Fedora carry: http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.2-usbredirofs=50 And then the first 13 patches after: Merge tag 'v1.2.0' Oh, and also, if you're running qemu git master, make sure you've: http://cgit.freedesktop.org/~jwrdegoede/qemu/commit/?id=81e34f5973d8d6a1ef998a50c4a4bf66abb3b56b I used qemu-kvm-1.2-usbredir^ (the last commit is apparently broken - copypaste bug?). Yeah, that has been fixed now. I'm getting this right after typing cat /dev/ACM0 in the guest. It's an endless stream, and so is the output in the guest although there should be nothing to dump (that's the proper behaviour on the host). Hmm, can you try commenting out line 1608 of hw/usb/redirect.c: usb_ep-pipeline = true; And see if that helps. If it does not help, please bump the debug level to 5 (this will also make it log packet contents), and then generate another log, and then it is time to dive into the ACM protocol to see what is happening... As it looks like now, I was just using the wrong test on the guest side. Retried this morning briefly with a terminal program, and it was all fine, even when forwarding from host-ehci to guest-uhci (with my broken patch), even when using current QEMU git head. Sorry for the noise Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
Hi, On 09/21/2012 01:49 PM, Jan Kiszka wrote: On 2012-09-18 11:41, Hans de Goede wrote: Hi, On 09/17/2012 06:22 PM, Jan Kiszka wrote: If that does not work, add the debug parameter to the usb-redir device, set it to 4, collect logs of trying to redirect the device and send me the logs please, ie: -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4 Also be aware that usb-redir relies on chardev flowcontrol working, which it does not upstream! See for example here for the chardev flow control patch set which RHEL / Fedora carry: http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.2-usbredirofs=50 And then the first 13 patches after: Merge tag 'v1.2.0' Oh, and also, if you're running qemu git master, make sure you've: http://cgit.freedesktop.org/~jwrdegoede/qemu/commit/?id=81e34f5973d8d6a1ef998a50c4a4bf66abb3b56b I used qemu-kvm-1.2-usbredir^ (the last commit is apparently broken - copypaste bug?). Yeah, that has been fixed now. I'm getting this right after typing cat /dev/ACM0 in the guest. It's an endless stream, and so is the output in the guest although there should be nothing to dump (that's the proper behaviour on the host). Hmm, can you try commenting out line 1608 of hw/usb/redirect.c: usb_ep-pipeline = true; And see if that helps. If it does not help, please bump the debug level to 5 (this will also make it log packet contents), and then generate another log, and then it is time to dive into the ACM protocol to see what is happening... As it looks like now, I was just using the wrong test on the guest side. Retried this morning briefly with a terminal program, and it was all fine, even when forwarding from host-ehci to guest-uhci (with my broken patch), even when using current QEMU git head. Sorry for the noise Ok, so to be clear: this is solved now, right ? Regards, Hans
Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
On 2012-09-21 14:21, Hans de Goede wrote: Hi, On 09/21/2012 01:49 PM, Jan Kiszka wrote: On 2012-09-18 11:41, Hans de Goede wrote: Hi, On 09/17/2012 06:22 PM, Jan Kiszka wrote: If that does not work, add the debug parameter to the usb-redir device, set it to 4, collect logs of trying to redirect the device and send me the logs please, ie: -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4 Also be aware that usb-redir relies on chardev flowcontrol working, which it does not upstream! See for example here for the chardev flow control patch set which RHEL / Fedora carry: http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.2-usbredirofs=50 And then the first 13 patches after: Merge tag 'v1.2.0' Oh, and also, if you're running qemu git master, make sure you've: http://cgit.freedesktop.org/~jwrdegoede/qemu/commit/?id=81e34f5973d8d6a1ef998a50c4a4bf66abb3b56b I used qemu-kvm-1.2-usbredir^ (the last commit is apparently broken - copypaste bug?). Yeah, that has been fixed now. I'm getting this right after typing cat /dev/ACM0 in the guest. It's an endless stream, and so is the output in the guest although there should be nothing to dump (that's the proper behaviour on the host). Hmm, can you try commenting out line 1608 of hw/usb/redirect.c: usb_ep-pipeline = true; And see if that helps. If it does not help, please bump the debug level to 5 (this will also make it log packet contents), and then generate another log, and then it is time to dive into the ACM protocol to see what is happening... As it looks like now, I was just using the wrong test on the guest side. Retried this morning briefly with a terminal program, and it was all fine, even when forwarding from host-ehci to guest-uhci (with my broken patch), even when using current QEMU git head. Sorry for the noise Ok, so to be clear: this is solved now, right ? Let's consider it solved until I find a real bug. ;) Will send some update for the speed matching patch on the weekend, probably. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
Hi, On 09/18/2012 11:18 PM, Anthony Liguori wrote: Hans de Goede hdego...@redhat.com writes: Hi, On 09/17/2012 11:18 AM, Jan Kiszka wrote: On 2012-09-17 11:08, Hans de Goede wrote: snip Although not pretty I'm ok with this, since I actually want to add similar code to allow usb-3 (superspeed) devices like a usb-3 usb-stick to work with ehci or uhci controllers :) Great, that would have been my next question, but I don't have hardware for that around yet. I do have hardware for that around, so once you've respun your patch to address the issues discussed, then that will give me a nice basis to add usb-3 usb-stick to ehci-controller redirection :) BTW, I'm facing several incompatibilities with passed-through CDC/ACM devices (e.g. a Galaxy S2), independent of my patch. Both host-linux and redir doesn't allow to use them properly but show different symptoms. Need to analyze and report once time permits. Hmm, there is (was) one know issues with these devices, which has been fixed in usbredir, so first of all make sure that the usbredir on your spice-client / usbredirserver, has this patch: http://cgit.freedesktop.org/spice/usbredir/commit/?id=7783d3db61083bbf7f61b1ea8608c666b4c6a1dd If that does not work, add the debug parameter to the usb-redir device, set it to 4, collect logs of trying to redirect the device and send me the logs please, ie: -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4 Also be aware that usb-redir relies on chardev flowcontrol working, which it does not upstream! See for example here for the chardev flow control patch set which RHEL / Fedora carry: http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.2-usbredirofs=50 Those patches are garbage. sigh, very very deep sigh No they are not garbage. They: 1) Fix a real issue, which is independent of spice / usb-redir but happens to be more easily triggerable with them. Note that the original set was developed to fix a bug which did not involve either! 2) Are disliked by you because they build upon the existing not pretty chardev code. We all agree that needs a rewrite. But that is not a valid reason to keep this perfectly fine patchset out of qemu master for years now! 3) You keep saying they are racy, but you've never given a simple step by step thread 1 does foo, thread 2 does bar replay of such a theoretical race. 4) Have caused no issues in almost 2 years of deployment in the field in both RHEL and Fedora. 5) Are kept out of master by you for no valid reasons, you seem to use them as a tool to strongarm people into rewriting the qemu chardev layer. Well it seems that no one is biting because of -ENOTIME, so can we now please get these included, after almost 2 years since their first posting ? Are you saying that usb-redir doesn't work in qemu.git? So why are we even carrying it? It works just as well as virtio-console or any other chardev frontend, any chardev frontent can currently trigger asserts by writing data faster then the backend can handle. This is just more easily triggerable with USB trafic then with a serial console. The original bug-report this patch set once was written for was about virtio-console and is dated 2010-08-05 ! So why are we even carrying virtio-console ? Regards, Hans p.s. Note that I'm *not* the original author of these patches.
Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
Hi, On 09/17/2012 06:22 PM, Jan Kiszka wrote: If that does not work, add the debug parameter to the usb-redir device, set it to 4, collect logs of trying to redirect the device and send me the logs please, ie: -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4 Also be aware that usb-redir relies on chardev flowcontrol working, which it does not upstream! See for example here for the chardev flow control patch set which RHEL / Fedora carry: http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.2-usbredirofs=50 And then the first 13 patches after: Merge tag 'v1.2.0' Oh, and also, if you're running qemu git master, make sure you've: http://cgit.freedesktop.org/~jwrdegoede/qemu/commit/?id=81e34f5973d8d6a1ef998a50c4a4bf66abb3b56b I used qemu-kvm-1.2-usbredir^ (the last commit is apparently broken - copypaste bug?). Yeah, that has been fixed now. I'm getting this right after typing cat /dev/ACM0 in the guest. It's an endless stream, and so is the output in the guest although there should be nothing to dump (that's the proper behaviour on the host). Hmm, can you try commenting out line 1608 of hw/usb/redirect.c: usb_ep-pipeline = true; And see if that helps. If it does not help, please bump the debug level to 5 (this will also make it log packet contents), and then generate another log, and then it is time to dive into the ACM protocol to see what is happening... Regards, Hans
Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
Hans de Goede hdego...@redhat.com writes: Hi, On 09/17/2012 11:18 AM, Jan Kiszka wrote: On 2012-09-17 11:08, Hans de Goede wrote: snip Although not pretty I'm ok with this, since I actually want to add similar code to allow usb-3 (superspeed) devices like a usb-3 usb-stick to work with ehci or uhci controllers :) Great, that would have been my next question, but I don't have hardware for that around yet. I do have hardware for that around, so once you've respun your patch to address the issues discussed, then that will give me a nice basis to add usb-3 usb-stick to ehci-controller redirection :) BTW, I'm facing several incompatibilities with passed-through CDC/ACM devices (e.g. a Galaxy S2), independent of my patch. Both host-linux and redir doesn't allow to use them properly but show different symptoms. Need to analyze and report once time permits. Hmm, there is (was) one know issues with these devices, which has been fixed in usbredir, so first of all make sure that the usbredir on your spice-client / usbredirserver, has this patch: http://cgit.freedesktop.org/spice/usbredir/commit/?id=7783d3db61083bbf7f61b1ea8608c666b4c6a1dd If that does not work, add the debug parameter to the usb-redir device, set it to 4, collect logs of trying to redirect the device and send me the logs please, ie: -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4 Also be aware that usb-redir relies on chardev flowcontrol working, which it does not upstream! See for example here for the chardev flow control patch set which RHEL / Fedora carry: http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.2-usbredirofs=50 Those patches are garbage. Are you saying that usb-redir doesn't work in qemu.git? So why are we even carrying it? Regards, Anthony Liguori And then the first 13 patches after: Merge tag 'v1.2.0' Oh, and also, if you're running qemu git master, make sure you've: http://cgit.freedesktop.org/~jwrdegoede/qemu/commit/?id=81e34f5973d8d6a1ef998a50c4a4bf66abb3b56b Regards, Hans
Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
Hi,
On 09/15/2012 06:27 PM, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
This follows the logic of host-linux: If a 2.0 device has no ISO
endpoint and no interrupt endpoint with a packet size 64, we can
attach it also to an 1.1 host controller. In case the redir server does
not report endpoint sizes, play safe and remove the 1.1 compatibility as
well.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Interesting thanks for the patch. I like the approach you took (simple code),
but unfortunately it won't work, if you look at usbredir_device_connect(),
where you do the dev-dev.speedmask |= USB_SPEED_MASK_FULL, it also
actually attaches the device to the controller, from which point on the
guest will see the device.
What happens on the wire is that the usbredir-host sends (in order):
-ep_info + interface_info
-device_connect message
So your clearing of the speed-mask will never trigger, unless ep-info
gets repeated later (which it does under certain circumstances).
I suggest instead changing the code to set a fullspeed_compatible flag
in struct USBRedirDevice from usbredir_device_disconnect(), clear that
flag from usbredir_ep_info and use it to add to the mask in
usbredir_device_connect().
###
Another issue is what happens if a device grows incompatible endpoints
after being attached, ie a webcam could have no isoc endpoints in alt
setting 0, and then grow an isoc endpoint on a set_interface. So we
would need a check for a device becoming not fullspeed compat while
being attached at fullspeed in usbredir_ep_info(), and then call
usbredir_reject_device() when this happens.
Although not pretty I'm ok with this, since I actually want to add
similar code to allow usb-3 (superspeed) devices like a usb-3 usb-stick
to work with ehci or uhci controllers :)
Regards,
Hans
---
hw/usb/redirect.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index 5301a69..bc36e53 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -1098,6 +1098,9 @@ static void usbredir_device_connect(void *priv,
}
dev-dev.speedmask = (1 dev-dev.speed);
+if (dev-dev.speed == USB_SPEED_HIGH) {
+dev-dev.speedmask |= USB_SPEED_MASK_FULL;
+}
dev-device_info = *device_connect;
if (usbredir_check_filter(dev)) {
@@ -1172,7 +1175,14 @@ static void usbredir_ep_info(void *priv,
case usb_redir_type_invalid:
break;
case usb_redir_type_iso:
+dev-dev.speedmask = ~USB_SPEED_MASK_FULL;
+/* Fall through */
case usb_redir_type_interrupt:
+if (!usbredirparser_peer_has_cap(dev-parser,
+ usb_redir_cap_ep_info_max_packet_size) ||
+ep_info-max_packet_size[i] 64) {
+dev-dev.speedmask = ~USB_SPEED_MASK_FULL;
+}
if (dev-endpoint[i].interval == 0) {
ERROR(Received 0 interval for isoc or irq endpoint\n);
usbredir_device_disconnect(dev);
Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
On 2012-09-17 11:08, Hans de Goede wrote: Hi, On 09/15/2012 06:27 PM, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com This follows the logic of host-linux: If a 2.0 device has no ISO endpoint and no interrupt endpoint with a packet size 64, we can attach it also to an 1.1 host controller. In case the redir server does not report endpoint sizes, play safe and remove the 1.1 compatibility as well. Signed-off-by: Jan Kiszka jan.kis...@siemens.com Interesting thanks for the patch. I like the approach you took (simple code), but unfortunately it won't work, if you look at usbredir_device_connect(), where you do the dev-dev.speedmask |= USB_SPEED_MASK_FULL, it also actually attaches the device to the controller, from which point on the guest will see the device. What happens on the wire is that the usbredir-host sends (in order): -ep_info + interface_info -device_connect message So your clearing of the speed-mask will never trigger, unless ep-info gets repeated later (which it does under certain circumstances). Hmm, what a pity... I suggest instead changing the code to set a fullspeed_compatible flag in struct USBRedirDevice from usbredir_device_disconnect(), clear that flag from usbredir_ep_info and use it to add to the mask in usbredir_device_connect(). OK. ### Another issue is what happens if a device grows incompatible endpoints after being attached, ie a webcam could have no isoc endpoints in alt setting 0, and then grow an isoc endpoint on a set_interface. So we would need a check for a device becoming not fullspeed compat while being attached at fullspeed in usbredir_ep_info(), and then call usbredir_reject_device() when this happens. ...and this patch started so simple. OK. Although not pretty I'm ok with this, since I actually want to add similar code to allow usb-3 (superspeed) devices like a usb-3 usb-stick to work with ehci or uhci controllers :) Great, that would have been my next question, but I don't have hardware for that around yet. BTW, I'm facing several incompatibilities with passed-through CDC/ACM devices (e.g. a Galaxy S2), independent of my patch. Both host-linux and redir doesn't allow to use them properly but show different symptoms. Need to analyze and report once time permits. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
Hi, On 09/17/2012 11:18 AM, Jan Kiszka wrote: On 2012-09-17 11:08, Hans de Goede wrote: snip Although not pretty I'm ok with this, since I actually want to add similar code to allow usb-3 (superspeed) devices like a usb-3 usb-stick to work with ehci or uhci controllers :) Great, that would have been my next question, but I don't have hardware for that around yet. I do have hardware for that around, so once you've respun your patch to address the issues discussed, then that will give me a nice basis to add usb-3 usb-stick to ehci-controller redirection :) BTW, I'm facing several incompatibilities with passed-through CDC/ACM devices (e.g. a Galaxy S2), independent of my patch. Both host-linux and redir doesn't allow to use them properly but show different symptoms. Need to analyze and report once time permits. Hmm, there is (was) one know issues with these devices, which has been fixed in usbredir, so first of all make sure that the usbredir on your spice-client / usbredirserver, has this patch: http://cgit.freedesktop.org/spice/usbredir/commit/?id=7783d3db61083bbf7f61b1ea8608c666b4c6a1dd If that does not work, add the debug parameter to the usb-redir device, set it to 4, collect logs of trying to redirect the device and send me the logs please, ie: -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4 Also be aware that usb-redir relies on chardev flowcontrol working, which it does not upstream! See for example here for the chardev flow control patch set which RHEL / Fedora carry: http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.2-usbredirofs=50 And then the first 13 patches after: Merge tag 'v1.2.0' Oh, and also, if you're running qemu git master, make sure you've: http://cgit.freedesktop.org/~jwrdegoede/qemu/commit/?id=81e34f5973d8d6a1ef998a50c4a4bf66abb3b56b Regards, Hans
Re: [Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
On 2012-09-17 16:24, Hans de Goede wrote: Hi, On 09/17/2012 11:18 AM, Jan Kiszka wrote: On 2012-09-17 11:08, Hans de Goede wrote: snip Although not pretty I'm ok with this, since I actually want to add similar code to allow usb-3 (superspeed) devices like a usb-3 usb-stick to work with ehci or uhci controllers :) Great, that would have been my next question, but I don't have hardware for that around yet. I do have hardware for that around, so once you've respun your patch to address the issues discussed, then that will give me a nice basis to add usb-3 usb-stick to ehci-controller redirection :) BTW, I'm facing several incompatibilities with passed-through CDC/ACM devices (e.g. a Galaxy S2), independent of my patch. Both host-linux and redir doesn't allow to use them properly but show different symptoms. Need to analyze and report once time permits. Hmm, there is (was) one know issues with these devices, which has been fixed in usbredir, so first of all make sure that the usbredir on your spice-client / usbredirserver, has this patch: http://cgit.freedesktop.org/spice/usbredir/commit/?id=7783d3db61083bbf7f61b1ea8608c666b4c6a1dd Included (I'm using 0.5 or even git head). If that does not work, add the debug parameter to the usb-redir device, set it to 4, collect logs of trying to redirect the device and send me the logs please, ie: -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=4 Also be aware that usb-redir relies on chardev flowcontrol working, which it does not upstream! See for example here for the chardev flow control patch set which RHEL / Fedora carry: http://cgit.freedesktop.org/~jwrdegoede/qemu/log/?h=qemu-kvm-1.2-usbredirofs=50 And then the first 13 patches after: Merge tag 'v1.2.0' Oh, and also, if you're running qemu git master, make sure you've: http://cgit.freedesktop.org/~jwrdegoede/qemu/commit/?id=81e34f5973d8d6a1ef998a50c4a4bf66abb3b56b I used qemu-kvm-1.2-usbredir^ (the last commit is apparently broken - copypaste bug?). I'm getting this right after typing cat /dev/ACM0 in the guest. It's an endless stream, and so is the output in the guest although there should be nothing to dump (that's the proper behaviour on the host). qemu-system-x86_64: usb-redir: ctrl-out type 0x21 req 0x22 val 0x3 index 1 len 0 id 93336 qemu-system-x86_64: usb-redir: ctrl-in status 0 len 0 id 93336 qemu-system-x86_64: usb-redir: interrupt recv started ep 83 qemu-system-x86_64: usb-redir: bulk-out ep 85 len 512 id 933359872 qemu-system-x86_64: usb-redir: interrupt recv status 0 ep 83 id 0 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 85 len 9 id 933359872 qemu-system-x86_64: usb-redir: bulk-out ep 85 len 512 id 933360192 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 85 len 0 id 933360192 qemu-system-x86_64: usb-redir: bulk-out ep 85 len 512 id 933360320 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 2 id 933362176 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 2 id 933362240 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 1 id 933362304 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 1 id 933362368 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 1 id 933362432 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 1 id 933362496 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 1 id 933362560 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 2 id 933362624 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 2 id 933362688 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 04 len 2 id 933362176 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 04 len 2 id 933362240 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 04 len 1 id 933362304 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 04 len 1 id 933362368 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 04 len 1 id 933362432 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 04 len 1 id 933362496 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 04 len 1 id 933362560 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 04 len 2 id 933362624 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 04 len 2 id 933362688 qemu-system-x86_64: usb-redir: interrupt-in status 0 ep 83 len 10 id 0 qemu-system-x86_64: usb-redir: interrupt-token-in ep 83 status 0 len 10 qemu-system-x86_64: usb-redir: interrupt-in status 0 ep 83 len 10 id 1 qemu-system-x86_64: usb-redir: interrupt-token-in ep 83 status 0 len 10 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 85 len 13 id 933360320 qemu-system-x86_64: usb-redir: bulk-out ep 85 len 512 id 933360448 qemu-system-x86_64: usb-redir: bulk-in status 0 ep 85 len 0 id 933360448 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 2 id 933362752 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 2 id 933362624 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 2 id 933362560 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 2 id 933362496 qemu-system-x86_64: usb-redir: bulk-out ep 04 len 1 id
[Qemu-devel] [PATCH] usb-redir: Allow to attach USB 2.0 devices to 1.1 host controller
From: Jan Kiszka jan.kis...@siemens.com
This follows the logic of host-linux: If a 2.0 device has no ISO
endpoint and no interrupt endpoint with a packet size 64, we can
attach it also to an 1.1 host controller. In case the redir server does
not report endpoint sizes, play safe and remove the 1.1 compatibility as
well.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/usb/redirect.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index 5301a69..bc36e53 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -1098,6 +1098,9 @@ static void usbredir_device_connect(void *priv,
}
dev-dev.speedmask = (1 dev-dev.speed);
+if (dev-dev.speed == USB_SPEED_HIGH) {
+dev-dev.speedmask |= USB_SPEED_MASK_FULL;
+}
dev-device_info = *device_connect;
if (usbredir_check_filter(dev)) {
@@ -1172,7 +1175,14 @@ static void usbredir_ep_info(void *priv,
case usb_redir_type_invalid:
break;
case usb_redir_type_iso:
+dev-dev.speedmask = ~USB_SPEED_MASK_FULL;
+/* Fall through */
case usb_redir_type_interrupt:
+if (!usbredirparser_peer_has_cap(dev-parser,
+ usb_redir_cap_ep_info_max_packet_size) ||
+ep_info-max_packet_size[i] 64) {
+dev-dev.speedmask = ~USB_SPEED_MASK_FULL;
+}
if (dev-endpoint[i].interval == 0) {
ERROR(Received 0 interval for isoc or irq endpoint\n);
usbredir_device_disconnect(dev);
--
1.7.3.4
