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

Segher Boessenkool segher at kernel.crashing.org
Fri Jul 14 08:31:52 AEST 2017

On Thu, Jul 13, 2017 at 03:18:23PM +0200, 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.
> 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?

That, or set up the prefetchable window to (partially) be below 4GB?


More information about the SLOF mailing list