[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] qemu, pci_passthrough, Error: Should not read BAR through QEMU


  • To: xen-users@xxxxxxxxxxxxx
  • From: "Jürgen Walter" <juwalter@xxxxxxxxx>
  • Date: Fri, 20 May 2016 00:01:13 +0200
  • Delivery-date: Thu, 19 May 2016 22:02:31 +0000
  • List-id: Xen user discussion <xen-users.lists.xen.org>

Hello list,

we have been stuck getting a custom uio driver to work using pci_passthrough, it runs into

"Error: Should not read BAR through QEMU"

https://github.com/qemu/qemu/blob/master/hw/xen/xen_pt.c#L434

I am using Debian stretch (testing) with Xen 4.6 as Dom0 and Ubuntu 14.04 i386 as PVHM guest.

The offending line seems to be

   iowrite32(0, info->mem[DPM_INDEX].internal_addr + DPM_HOST_INT_EN0);

after it has been remapped like so

  info->mem[DPM_INDEX].internal_addr = ioremap_nocache(
                pci_resource_start(dev, bar),
                pci_resource_len(dev, bar));

I already tried to remap the resource using instead

  pci_iomap(dev, bar, pci_resource_len(dev, bar));

however, no luck. (not, bar == 0)

The log output shows "internal_addr" at "0xF84C0000" - no matter if I use "ioremap_nocache" or "pci_iomap"

I am not clear how this is supposed to work in PCI and Xen land:

on the host/Dom0, output of "lspci -kvvvxs 06:00.0" is

        06:00.0 Unassigned class [ff00]: <company/product name omitted>
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-
                Interrupt: pin A routed to IRQ 16
                Region 0: Memory at f7a00000 (32-bit, non-prefetchable) 
[size=64K]
                Kernel driver in use: pciback
        00: cf 15 00 00 02 00 00 02 00 00 00 ff 00 15 00 00
        10: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00
        20: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
        30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00

on the guest/DomU, "lspci -kvvvxs 00:04.0" shows
        00:04.0 Unassigned class [ff00]: <company/product name omitted>
                Physical Slot: 4
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-
                Interrupt: pin A routed to IRQ 32
                Region 0: Memory at f3000000 (32-bit, non-prefetchable) 
[size=64K]
                Kernel driver in use: netx
        00: cf 15 00 00 02 00 00 02 00 00 00 ff 08 40 00 00
        10: 00 00 00 f3 00 00 00 00 00 00 00 00 00 00 00 00
        20: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
        30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00


To me, this looks all reasonable, Xen/IOMMU seem to do the right thing an properly map the device into the guest with a new memory region.

I am suspecting I am doing it wrong (iowrite32), when trying to write to the device.

Is the a "correct" way of mapping such PCI io resources into the kernel driver code, so that it does not land in the QEMU trap "xen_pt_bar_write"

Thanks!! Jürgen

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.