>>> On 06.06.17 at 12:41, <marma...@invisiblethingslab.com> wrote: > [root@dom0 ~]# lspci -s 00:14.0 -vvv > 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI > Controller (rev 03) (prog-if 30 [XHCI]) > Subsystem: Intel Corporation Device 7270 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0 > Interrupt: pin A routed to IRQ 170 > Region 0: Memory at b2200000 (64-bit, non-prefetchable) [size=64K] > Capabilities: [70] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA > PME(D0-,D1-,D2-,D3hot+,D3cold+) > Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ > Address: 00000000fee00338 Data: 0000
So as I did expect the field accessed is the MSI capability structure. Such accesses shouldn't reach pciback, but instead be taken care of by qemu. I can't really comment on the qemu side though, but this at least makes me think the underlying cause of the problems you see with the two controllers is the same. Is this a regression of some sort, i.e. did the same setup work in earlier Xen versions? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
