Re: [Qemu-devel] [PULL 14/28] exec: make address spaces 64-bit wide

[Alex Williamson <alex.williamson@redhat.com>]

On Tue, 2014-01-14 at 12:55 -0500, Mike Day wrote:
> On Tue, Jan 14, 2014 at 12:49 PM, Mike Day <ncmike@ncultra.org> 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