On 12/03/17 03:56, Michael S. Tsirkin wrote: > After looking at it some more, I think the issue is merely with how info > mtree presents information, which confuses instead of helping when > overlap triggers. Specifically > 000001ff00000000-000001ffffffffff (prio 0, i/o): pci-mmio > ... > 000001fe04040000-000001fe04043fff (prio 1, i/o): virtio-pci > > really means that virtio-pci is not visible at all, this > happens because it starts at offset ffffffff04040000 which is > outside the parent. > > I think that the cleanest fix is probably to show 128 bit addresses, > then user will see the real addresses: > > 000001ff00000000-000001ffffffffff (prio 0, i/o): pci-mmio > ... > 1000001fe04040000-1000001fe04043fff (prio 1, i/o): virtio-pci > > and now it's clear what is going on: virtio-pci is outside pci-mmio. > > This would have pointed Mark in the right direction earlier. > > Thoughts? Patch?
Presumably if someone tried to do this on real hardware, the BAR address would lie outside of the pci-mmio region and effectively isn't mapped? If this is the case I'd be happy with a simple qemu_log() showing the full 64-bit address and region name explaining that it couldn't be mapped underneath its parent because it was outside its parent region, and skip the mapping. ATB, Mark.
