Finish writeups/hackintosh/usbredir.md ...

- Add writeups/hackintosh entry in README.md

1 files changed, 62 insertions, 8 deletions

diff --git a/writeups/hackintosh/usbredir.md b/writeups/hackintosh/usbredir.md
index 7b1c744..0ca19a7 100644
--- a/writeups/hackintosh/usbredir.md
+++ b/writeups/hackintosh/usbredir.md
@@ -1,9 +1,10 @@
-That 10 ms delay is apparently detrimental. It makes sense because USB is meant
-to be work over short distances. The protocol and even the electrical
-characteristics are built upon this assumption. USB frames are short in length
-and polled frequently, and almost no buffering is done in the background as it
-works closely on the hardware. Therefore, performance hit is inevitable and
-instability issues are expected when USB frames are passed over IP.
+That 10+ ms delay is apparently detrimental. It makes sense because USB is
+designed to work over short distances. The protocol and (even) electrical
+characteristics are built upon this assumption. The USB frames are short in
+length and polled frequently, and almost no buffering is done in the background
+as it works closely on the hardware. Therefore, the performance hit is
+inevitable and instability issues are expected when USB frames are passed over
+IP.
 
 The usb-redir devices are attached via qemu command line passthrough.
 virt-manager is not "aware" of this and it doesn't even try to see if there usb
@@ -22,5 +23,58 @@ Some usb devices don't like getting passed around over the network.
 | Flash Drives | ✅YES | 🫳kinda(slow) |
 | HID(keyboard and mouse) | ✅YES | ✅YES |
 
-### Analysis: Android and IOS Devices
-TODO
+### TODO Analysis: Android and IOS Devices
+This is work in progress.
+
+Points:
+
+- To make XNU kernel happy, the devices must be attached to a hub. The kernel
+  cannot enumerate usb devices directly hot-plugged in the controller
+  - Performance hit due to the fact that qemu only supports emulation of
+    full-speed usb hub
+- Massive round-trip delay over the network in terms of USB(which speaks in
+  nanosecond terms)
+  - As a result, it's possible that Android and IOS devices initiate USB reset
+    rather than patiently sticking up with the delay (possibly)due to the
+    limitation of hardware/firmware(TODO: inspect Logcat and Xcode instruments
+    to verify it)
+- TODO: Instead of using USB redirection, USB devices can be attached to the
+  controller on guest start up
+- There are many components that make the USB redirection over network possible.
+  Quite possibly, the culprit could be one of the components along the chain
+- The issue is present on other proprietary solutions using VHCI as
+  well(FlexiHub, VirtualHere)
+  - meaning that it's likely the "massive round-trip delay" issue
+  - or it's a bug in the encapsulation protocol/implementation that's common in
+    all proprietary/FOSS implementation
+
+"The chain":
+
+```
+                  <- NET ->
+CLIENT                                  HOST
+tcp/ip                                  tcp/ip
+ssh                                     ssh
+spice+usbredir                          libvirt
+libusb                                  spice
+virt-viewer                             qemu
+                                        xhci
+                                        usb-hub
+                                        usb-redir
+```
+
+"The components"
+
+- virt
+  - ssh tunneling
+  - USB/IP
+  - SPICE
+  - libusb
+  - usbredir
+  - usb/ip
+- QEMU
+  - xhci
+  - usb-hub
+  - usb-redir
+- Apple
+  - Apple VHCI