Specifically, it is designed to handle multiple data transfer speeds (low, full, high, and SuperSpeed) within a single unified standard.
Additionally, xHCI simplifies the architecture needed to support a mixture of low-speed and high-speed devices, which streamlines the development of drivers and system software.
The xHCI architecture moves the control of this critical state into hardware, enabling USB resource management across VMs.
The xHCI virtualization features also provide for: The EHCI utilizes OHCI or UHCI controllers as "companion controllers", where USB 2 devices are managed through the EHCI stack, and the port logic of the EHCI allows a low-speed or full-speed USB device to be routed to a port of a "companion" UHCI or OHCI controller, where the low-speed or full-speed USB devices are managed through the respective UHCI or OHCI stack.
If a low-speed or full-speed USB device is attached to connectors 1 or 2, it will be routed to the root hub ports of one of the OHCI controllers for management, and low-speed and full-speed USB devices attached to connectors 3 or 4 will be routed to the root hub ports of the other OHCI controller.
Classically there has been a 1:1 relationship between a USB endpoint and a buffer in system memory, and the host controller solely responsible for directing all data transfers.
The xHCI architecture was designed to be highly scalable, capable of supporting 1 to 255 USB devices and 1 to 255 root hub ports.
Thus a vendor can scale their internal xHCI Endpoint Context cache space and resources to match the practical usage models expected for their products, rather than the architectural limits that they support.
Ideally the internal cache space is selected so that under normal usage conditions, there is no context paging by the xHCI.
The EHCI architecture was modeled after the UHCI and OHCI controllers, which required software to build the USB transaction schedules in memory, and to manage bandwidth and address allocation.
The EHCI licensing model was continued for Intel's xHCI specification, however with a greatly expanded industry contribution.
Most changes defined in the xHCI errata files are clarifications, grammatical or spelling corrections, additional cross-references, etc., which do not affect a driver implementation.