From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W38ND-0001RE-P7 for qemu-devel@nongnu.org; Tue, 14 Jan 2014 13:06:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W38N9-0003fH-Qg for qemu-devel@nongnu.org; Tue, 14 Jan 2014 13:05:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53050) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W38N9-0003f8-H5 for qemu-devel@nongnu.org; Tue, 14 Jan 2014 13:05:55 -0500 Message-ID: <1389722747.3209.474.camel@bling.home> From: Alex Williamson Date: Tue, 14 Jan 2014 11:05:47 -0700 In-Reply-To: References: <20140109180003.GA6819@redhat.com> <1389293278.3209.248.camel@bling.home> <1389294206.3209.249.camel@bling.home> <20140109215632.GB9385@redhat.com> <1389307342.3209.269.camel@bling.home> <20140110125504.GF10700@redhat.com> <1389367896.3209.291.camel@bling.home> <20140112075419.GB22644@redhat.com> <1389649144.3209.394.camel@bling.home> <20140114122122.GD28066@redhat.com> <1389714579.3209.446.camel@bling.home> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: Mike Day Cc: Peter Maydell , QEMU Developers , "Michael S. Tsirkin" , Alexey Kardashevskiy , Alexander Graf , Luiz Capitulino , Paolo Bonzini , David Gibson On Tue, 2014-01-14 at 12:55 -0500, Mike Day wrote: > On Tue, Jan 14, 2014 at 12:49 PM, Mike Day wrote: > >>> > > >>>>>>> > >>> > > >>>>>>>>> Prior to this change, there was no re-map with the fffffffffebe0000 > > > >> If we choose not to map them, how do we distinguish them from guest RAM? > >> There's no MemoryRegion flag that I'm aware of to distinguish a ram_ptr > >> that points to a chunk of guest memory from one that points to the mmap > >> of a device BAR. I think I'd need to explicitly walk all of the vfio > >> device and try to match the MemoryRegion pointer to one of my devices. > >> That only solves the problem for vfio devices and not ivshmem devices or > >> pci-assign devices. > >> > > > > I don't know if this will save you doing your memory region search or > > not. But a BAR that ends with the low bit set is MMIO, and BAR that > > ends with the low bit clear is RAM. So the address above is RAM as was > > pointed out earlier in the thread. If you got an ambitious address in > > the future you could test the low bit. But MMIO is deprecated > > according to http://wiki.osdev.org/PCI so you probably won't see it, > > at least for 64-bit addresses. > > s/ambitious/ambiguous/ > > The address above has already been masked. What you need to do is read > the BAR. If the value from the BAR end in '1', its MMIO. If it ends in > '10', its RAM. If it ends in '0n' its disabled. The first thing that > the PCI software does after reading the BAR is mask off the two low > bits. Are you perhaps confusing MMIO and I/O port? I/O port cannot be mmap'd on x86, so it can't be directly mapped. It also doesn't come through the address_space_memory filter. I/O port is deprecated, or at least discouraged, MMIO is not. Thanks, Alex