Gigabyte GA-990FXA-UD5 Port Addresses

As part of an effort to set up multiple Virtual Machines on a system based around the Gigabyte SKT-AM3+ 990FXA-UD5 Motherboard, I have mapped many of the controller addresses to help with passing through various ports to VMs. In particular, I'm interested in USB ports but I've included a few others as well.

I obtained the device addresses by using the lspci and lsusb commands in Arch Linux Xen kernel, systematically blocking each address / address pair at boot  and checking for the presence of a usb device (a mouse) which I plugged into each port in turn, running lsusb to see if the device was listed.

My efforts have resulted in the following table where device addresses are listed across the top and ports/headers are listed down the side. A green entry indicates that the port is active with that particular address blocked. A red entry signifies that that port is inactive for the particular address.

That is to say, red blocks show ports that are available for passthrough to VMs when the controller id is blocked.

	00:12.0 00:12.2	00:13.0 00:13.2	00:14.5	00:16.0 00:16.2	2:00.0	7:00.0	05:0e.0
Rear USB 2.0 leftmost bank
Rear USB 2.0 rightmost bank
Rear USB 3.0
Int f_USB1
Int f_USB2
Int f_USB3
Int USB 3.0
Rear Firewire
Int Firewire

There are some notable points;

• The internal USB header labelled 'f_usb2' appears to be shared between two controllers. With 00:12.x blocked, only the first channel is inactive. With 00:13.x blocked, the second channel becomes inactive.
• lspci lists a USB controller with address 00:14.5 but blocking that fails to make any port inactive. I'm not sure what it relates to.
• Both the interior and exterior firwire ports are managed by the same controller address meaning both would be passed through to a VM.
• The 8 rear USB 2.0 ports are linked to different controllers meaning they can be passed in discrete blocks of 4 (plus one of the ports on the Int f_USB2 header also linked to each block, meaning 5 ports in total on those addresses)
• Internal f_USB1 and f_USB3 headers are linked to the same controller.

Essentially, this all means that this board has 5 distinct sets of USB ports (including 2x sets of USB 3.0) that can be passed to VMs - more than enough for me to set up my planned 3x VMs.

This addressing maps to the physical ports as follows;

fig 1 - rear port controller addresses

fig 2 - internal header controller addresses