Do you know which device is writing to the BAR below? From the trace it appears it should be restoring the memory address to the BAR after writing all 1s to the BAR and reading back the contents. (the protocol for finding the length of the bar memory.)
On Thu, Jan 9, 2014 at 12:24 PM, Alex Williamson <alex.william...@redhat.com> wrote: > On Wed, 2013-12-11 at 20:30 +0200, Michael S. Tsirkin wrote: >> From: Paolo Bonzini <pbonz...@redhat.com> > vfio: vfio_pci_read_config(0000:01:10.0, @0x10, len=0x4) febe0004 > (save lower 32bits of BAR) > vfio: vfio_pci_write_config(0000:01:10.0, @0x10, 0xffffffff, len=0x4) > (write mask to BAR) Here the device should restore the memory address (original contents) to the BAR. > vfio: region_del febe0000 - febe3fff > (memory region gets unmapped) > vfio: vfio_pci_read_config(0000:01:10.0, @0x10, len=0x4) ffffc004 > (read size mask) > vfio: vfio_pci_write_config(0000:01:10.0, @0x10, 0xfebe0004, len=0x4) > (restore BAR) > vfio: region_add febe0000 - febe3fff [0x7fcf3654d000] > (memory region re-mapped) > vfio: vfio_pci_read_config(0000:01:10.0, @0x14, len=0x4) 0 > (save upper 32bits of BAR) > vfio: vfio_pci_write_config(0000:01:10.0, @0x14, 0xffffffff, len=0x4) > (write mask to BAR) and here ... > vfio: region_del febe0000 - febe3fff > (memory region gets unmapped) > vfio: region_add fffffffffebe0000 - fffffffffebe3fff [0x7fcf3654d000] > (memory region gets re-mapped with new address) > qemu-system-x86_64: vfio_dma_map(0x7fcf38861710, 0xfffffffffebe0000, 0x4000, > 0x7fcf3654d000) = -14 (Bad address) > (iommu barfs because it can only handle 48bit physical addresses) I looked around some but I couldn't find an obvious culprit. Could it be that the BAR is getting unmapped automatically due to x-intx-mmap-timeout-ms before the device has a chance to finish restoring the correct value to the BAR? Mike
