[SLOF] [PATCH] pci: Translate PCI addresses to host addresses at the end of map-in

Alexey Kardashevskiy aik at ozlabs.ru
Fri Jul 14 14:59:07 AEST 2017

On 13/07/17 23:18, Thomas Huth wrote:
> On 13.07.2017 15:07, Thomas Huth wrote:
>> Currently, it is not possible to use VGA devices attached to a
>> PCI bridge on board-qemu, e.g. by starting QEMU like this:
>>  qemu-system-ppc64 -nodefaults -device pci-bridge,id=br1,chassis_nr=1 \
>>         -serial mon:stdio -device VGA,id=video,bus=br1,addr=1
>> One of the problems is the missing translate-address at the end
>> of the map-in function of the bridge - which was already marked
>> as a TODO, but apparently has never been enabled. So let's do
>> that now!
> The second problem is uglier, and I'm not quite sure what's the best way
> to fix it yet: The first BAR of the VGA device is a 32-bit prefetchable
> BAR, which is initialized via assign-mem32-bar and thus using the value
> from pci-next-mem. Now the bridge has only two windows, one for 64-bit
> prefetchable memory (configured via pci-next-mem64 here), and one for
> 32-bit non-prefetchable memory (configured via pci-next-mmio). So the
> VGA device ends up with a memory region that is not covered by the bridge.

VGA should be under 32bit non-prefetchable window, what is the problem with
putting it there? VGA's BAR being prefetchable means that a bridge can
prefetch from it but it does not have to, no?

> Should we maybe rather configure 32-bit prefetchable BARs via
> pci-next-mmio instead of pci-next-mem if the 64-bit pci-next-mem64 is
> available and used for bridges? Or has anybody any other suggestions how
> to fix this properly?


More information about the SLOF mailing list