xemu
xemu copied to clipboard
xemu-project
OHCI: Fixed a bug in the OHCI implementation from QEMU
This fixes the issue with USB passthrough in which a race condition is created when using the async api in libusb to write to and read from multiple endpoints simultaneously
Addresses this bug: https://github.com/xemu-project/xemu/issues/1239
Since this an issue with QEMU, should this perhaps be posted to the ML for comments / future merge?
Yes, it should. I'll need to look into what their patch submission process is
This fixes the issue with USB passthrough in which a race condition is created when using the async api in libusb to write to and read from multiple endpoints simultaneously
Can you share more specifics about the race condition to help me understand the root cause of the issue?
Every USBEndpoint that shares a single OCHI Controller shares a single buffer for reading and writing data. The libsub async API returns after sending a request and responses are handled later.
If a read request is sent and a write request is sent after the read request is sent but before the response comes in, then the read request has a chance to return data from the write request. I observed this while using the Steel Battalion controller but also while using the gamepad.
Converting the libusb passthrough code to use the sync API fixes the issue by blocking on every read and write request. This introduces latency so fixing the code to work properly with the async API is preferred.
And here I was, spending my day thinking I borked something in my USB driver.
This PR appears to resolve the issue stated in #1239. I was able to verify this with Stellar's Xbox One driver where we were running into endpoint data appearing in endpoint interrupts under xemu. With the patch, I was able to verify that the correct behavior matches that of our hw tests.
I look forward to reviewing the patch once @mborgerson's comments are addressed.
@faha223 would you mind dropping me an email? ([email protected]). Thank you for your contribution.
