From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48004) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Ipx-0003L4-4w for qemu-devel@nongnu.org; Mon, 20 Jan 2014 12:40:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5Ipr-0003MP-1d for qemu-devel@nongnu.org; Mon, 20 Jan 2014 12:40:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:12554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5Ipp-0003LY-U8 for qemu-devel@nongnu.org; Mon, 20 Jan 2014 12:40:30 -0500 Date: Mon, 20 Jan 2014 19:04:44 +0200 From: "Michael S. Tsirkin" Message-ID: <20140120170444.GC13804@redhat.com> References: <1386786509-29966-14-git-send-email-mst@redhat.com> <1389288287.3209.231.camel@bling.home> <1390236325.8705.160.camel@bling.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1390236325.8705.160.camel@bling.home> Subject: Re: [Qemu-devel] [PULL 14/28] exec: make address spaces 64-bit wide List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: Mike Day , Paolo Bonzini , "qemu-devel@nongnu.org" , Luiz Capitulino On Mon, Jan 20, 2014 at 09:45:25AM -0700, Alex Williamson wrote: > On Mon, 2014-01-20 at 11:20 -0500, Mike Day wrote: > > 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.) > > The guest itself is writing the the BARs. This is a standard sizing > operation by the guest. Question is maybe device memory should be disabled? Does windows do this too (sizing when memory enabled)? > > On Thu, Jan 9, 2014 at 12:24 PM, Alex Williamson > > wrote: > > > On Wed, 2013-12-11 at 20:30 +0200, Michael S. Tsirkin wrote: > > >> From: Paolo Bonzini > > > 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. > > Sorry if it's not clear, the trace here is what the vfio-pci driver > sees. We're just observing the sizing operation of the guest, therefore > we see: > > 1) orig = read() > 2) write(0xffffffff) > 3) size_mask = read() > 4) write(orig) > > We're only at step 2) > > > > 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) > > step 3) > > > > vfio: vfio_pci_write_config(0000:01:10.0, @0x10, 0xfebe0004, len=0x4) > > > (restore BAR) > > step 4) > > > > 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 ... > > This is the same as above to the next BAR, which is the upper 32bits of > the 64bit BAR. > > > > 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? > > No, this is simply the guest sizing the BAR, this is not an internally > generated operation. The INTx emulation isn't used here as KVM > acceleration is enabled. That also only toggles the enable setting on > the mmap'd MemoryRegion, it doesn't change the address it's mapped to. > Thanks, > > Alex