[vfio-users] Trying to pass through USB controller.

Andrew A. andj2223 at gmail.com
Fri Sep 1 03:45:18 UTC 2017


Hi,

I just wanted to follow up, all these months later, since I finally
got a chance to try this.
Unfortunately, I ran into some trouble. Perhaps you have some ideas:

On Sun, Mar 5, 2017 at 11:41 AM, Samuel Holland <samuel at sholland.org> wrote:
> Sorry for the delay getting back to you,
>
> On 03/01/17 14:32, Andrew A. wrote:
>>
>> Does anyone know of a sensible way to more permanently set the port
>> routing mask so it survives these pci resets?
>
>
> Unfortunately, the xHCI controller fully controls which ports go where.
> That means if you give it to the guest, since the guest driver controls
> the PCI device, it controls the ports too. It's not necessarily the PCI
> reset causing the switch--see for example the Linux driver:
>
> http://lxr.free-electrons.com/source/drivers/usb/host/pci-quirks.c#L926
>
> It moves all available ports to xHCI on powerup (including waking up
> from runtime power-management). What you can try is setting the "xHC USB
> 2.0 Port Routing Mask Register" (section 16.1.37 in the 9 series PCH
> datasheet). If you look at line 930 of the source linked above, you see
> that the Linux driver only tries to switch the ports marked as
> switchable. This should also work on Windows guests, as the datasheet
> specifies "When set to 0, The OS shall not modify the corresponding
> USB2HCSEL bit". Of course, since it's closed-source, there's no way to
> know if Windows behaves properly without trying.
>
> Masking off those ports so the OS doesn't switch them should not prevent
> you from switching them manually. This also means that even if you get
> the guest drivers to cooperate, a malicious application running in the
> guest could take over your keyboard.

I tried the following to no avail:
setpci -s 00:14.0 0xd4.L=0x00000000
setpci -s 00:14.0 0xdc.L=0x00000000

This seems not to have taken hold upon readback:
setpci -s 00:14.0 0xd4.L
00003fff
setpci -s 00:14.0 0xdc.L
0000003f

(And indeed, the same problem persists -- qemu changes the port
mappings as soon as I boot a guest, locking me out of my host machine
until I ssh in and run 'setpci .. d0' again)

I took a look at what I believe is the R/WL property for these
settings, which is bit 31 of D20:F0:40h according to the datasheet,
so:
setpci -s 00:14.0 0x40.L
803609fd
sudo setpci -s 00:14.0 0x40.L=0x003609fd

But this again didn't seem to have an effect:
setpci -s 00:14.0 0x40.L
803609fd

> Another potential problem is that your BIOS on the host may
> write-protect the mask register. In that case, see the datasheet for how
> to unlock it, if possible.

Right, and despite trying to remove the write protect I'm inclined to
think my unlocking commands are not working for some reason. Do you
see anything wrong with what I've tried here?

Thanks.




More information about the vfio-users mailing list