Project ACRN USB mediator introduction

1. ACRN USB Mediator Introduction
LIU Long
Liu, Long <Long.Liu@intel.com>
05/06/2020

2. Agenda
• USB architecture overview
• xHCI virtualization
• DRD virtualization
• Questions

3. USB native architecture
Android OS
Intel APL hardware
User
Kernel
xHCI controller xDCI
Controller
native xDCI Driver
native xHCI
Driver
DRD driver
usb subsystemsys I/F
PHY MUX control
USB2 PHY USB3 PHY
PHY MUX
Intel ApolloLake platform
integrated one xHCI controller and
one xDCI controller. One of xHCI
controller port shares same
couple USB Phys with xDCI
controller.
Inside of xHCI controller, there
has two vender extended
registers to support this couple
USB Phys switching.
The Apple Carplay feature require
the OTG functionality, its control
protocol implement base on USB
host mode, and batch data
transfer will over USB peripheral
mode. So it will trigger USB role
switch at appropriate time.
gadget
subsystem
role switch
CarPlay
application

4. USB device model architecture
Service OS
ACRN Hypervisor
User OS
User OS
APL hardware
User OS
User
Kernel
xHCI controller xDCI
Controller
native xDCI Driver
native Intel DRD
Driver
native xHCI
Driver
SW Role Switch
sys I/F
CarPlay
Application
xHCI DM
User
Kernel
native xHCI
Driver
native DRD
Driver
usbfssys I/F
PHY MUX control
USB2 PHY USB3 PHY
PHY MUX
VT-D
DRD DM
acrn-dm
xHCI emulator provides multiple
instances of virtual xHCI controller
to share among multiple User Oss,
each USB port can be dedicatedly
assigned to a VM.
xDCI controller can be passed
through to the specific user OS
with I/O MMU assistance.
DRD device model emulate the
APL PHY MUX control logic. The
frontend re-use the native Intel
USB role driver directly which
provides sysfs interface to user
space of user OS to switch
DCI/HCI role in CarPlay SW.
usb subsystemgadget
subsystem

5. Agenda
• USB architecture overview
• xHCI virtualization
• DRD virtualization
• Questions

6. APL MRB Board
Intel APL xHCI hardware design
APL SOC
USB1-mouse USB3-disk USB1-keyboard
Physical xHCI controller
USB2-roothub
1-1 1-2 1-3
USB3-roothub
2-1 2-2 2-3
hs phy ss phy hs phyhs phy ss phy
USB device naming format:
bus-port:config.intf
USB port naming format:
bus-port
The xHCI controller in Intel APL platform
includes 6 usb ports
3 * USB2 ports: 1-1, 1-2, 1-3
3 * USB3 ports: 2-1, 2-2, 2-3
There have 3 USB receptacles on APL
MRB board
One USB 3.0 OTG receptacle:
“1-1”+“2-1”
One USB 3.0 standard A receptacle:
“1-2”+ “2-2”
One USB 2.0 standard A receptacle:
“1-3”

7. ACRN Hypervisor
User OS
User OS
Service OS
APL hardware
User OS
User
Kernel
acrn-dm
xHCI controller
native Intel DRD
Driver
native xHCI
Driver
SW Role Switch
sys I/F
CarPlay
Application
xHCI DM
User
Kernel
native xHCI Drivernative DRD Driver
usbfs
sys I/F
PHY MUX control
DRD DM
USB Core
USB Port Mapper
libusb
xHCI virtualization architecture
'xHCI DM' emulates the xHCI
controller logic followed xHCI
spec;
'USB core' is a middle abstract
layer to isolate the USB controller
emulators and USB device
emulators.
‘USB Port Mapper’ is used to
mapping the native physical
specific USB ports to virtual USB
ports. It communicates with native
USB ports by libusb.
All the USB data buffer from UOS
(User OS) are in the form of TRB
(Transfer Request Block)
according to xHCI spec. And xHCI
DM will fetch these data buffers
once related xHCI doorbell
registers be set. Then these data
will convert to struct
usb_data_xfer and through USB
core forward to USB port mapper
module which will communicate
with native USB stack over libusb,
vice versa.

8. xHCI DM usage
The device model configuration command syntax for xHCI is as follows:
-s <slot>,xhci,[bus1-port1:bus2-port2]
slot: virtual PCI slot number in DM;
bus-port: this parameter used to specific which physical USB ports need to map to UOS.
For example:
-s 7,xhci,1-2:2-2
This parameter will expose one virtual PCI xHCI controller with 00:07:0 BDF.
This virtual xHCI controller integrated 10 virtual usb2 ports and 10 virtual usb3 ports. Its virtual 1-1 port will map to
physical 1-2 port, and virtual 2-1 port map to physical 2-2 port. Other virtual ports are reserved for physical HUB port
support.

9. Agenda
• USB architecture overview
• xHCI virtualization
• DRD virtualization
• Questions

10. Traditional OTG solution
• Tradition USB OTG solution uses one single
USB OTG controller for support
OTG/Device/Host mode.
• All USB2&USB3&ID signals will connect one
pair USB2&USB3 PHY which connect to OTG
controller directly.
• The OTG mode inside of OTG controller will
monitor ID/VBUS change and report to the
OTG driver.
• OTG driver should configure a set of registers
to switch Host mode and Device mode
followed ID/VBUS state.

11. Intel Dual Role Device solution
APL MRB Board
APL SOC
USB1-mouse USB3-disk USB1-keyboard
Physical xHCI controller
USB2-roothub
1-1 1-2 1-3
USB3-roothub
2-1 2-2 2-3
hs phy ss phy hs phy
Physical xDCI controller
usb2 port usb3 port
hs phy ss phy
phy mux
phy mux
control
• Dual Role implementation on Intel
APL platform uses separated xDCI
and xHCI controller to support the
OTG port.
• There has one pair USB2&USB3
PHY shared between xDCI and one
port of xHCI. And ID/VBUS signals
be monitored by other
component(like PMIC/Charger IC)
• Inside of xHCI controller, there has
one “phy mux control” logic to
support switch shared phy route
path.

12. Simplified DRD/OTG state-machine
• Disconnect State
• State Entry: No cable plugged in the OTG port.
• State Exit: Connect USB host or USB micro A cable.
• Device State:
• State Entry: Plug in USB micro B cable with USB host connection which trigger VBUS valid.
• State Exit: Disconnect USB host cause VBUS drop then transit to Disconnect State.
• Host State:
• State Entry: Plug in USB micro A cable make the ID ground.
• State Exit: Plug out USB micro A cable cause ID float then transit to Disconnect State.
Disconnect State Host StateDevice State
VBUS
Valid
VBUS
Drop
ID Ground
ID Float

13. DRD virtualization architecture
ACRN emulates the DRD
hardware logic of Intel Apollo
Lake platform to support the dual
role device requirement.
DRD feature implemented as
xHCI vendor extended capability
on Intel Apollo Lake platform,
ACRN emulates in the same way,
so the native driver can be re-
used in UOS.
Once UOS DRD driver
reads/writes the related xHCI
extended registers, these access
will be captured by xHCI DM. And
xHCI DM will do the Host/Device
mode switch operations through
native DRD related sysfs
interface.
ACRN Hypervisor
User OS
User OS
Service OS
APL hardware
User OS
User
Kernel
acrn-dm
xHCI controller
Native Intel DRD
Driver
Native xDCI
Driver
SW Role Switch
Sys I/F
CarPlay
Application
xHCI DM
User
Kernel
Native DRD Driver
Sys I/F
PHY MUX control
DRD DM
Native xDCI
Driver

14. DRD DM usage
The device model configuration command syntax for xHCI DRD is as follows:
-s <slot>,xhci,[bus1-port1:bus2-port2]:cap=platform
cap: cap means virtual xHCI capability, this parameter uses to indicate virtual xHCI should emulate which platform’s
xHCI capabilities.
For example:
-s 7,xhci,1-2:2-2:cap=apl
This parameter will expose one virtual PCI xHCI controller with 00:07:0 BDF.
This virtual xHCI controller integrated 10 usb2 ports and 10 usb3 ports. Its virtual 1-1 port will map to physical 1-2 port,
and virtual 2-1 port map to physical 2-2 port. Other ports are reserved for physical HUB port support.
This virtual xHCI controller support Intel APL extend xHCI capability(i.e. DRD)

15. Questions?