Re: [Qemu-devel] [PATCH 2/3] Add a new PCI region type to supports 64 bit ranges

[Kevin O'Connor <kevin@koconnor.net>]

On Tue, Jan 03, 2012 at 04:14:58PM +0100, Gerd Hoffmann wrote:
> On 12/29/11 03:56, Kevin O'Connor wrote:
> > Tracking of 64bit prefmem sections separately from
> > regular prefmem sections doesn't make sense, because both need to be
> > allocated from the same pool when behind a bridge.
> 
> Yea, bridges make the picture a bit more complicated.  A bridge itself
> might not be 64bit capable, which makes it impossible to map devices
> behind it above 4G.  Likewise with multiple devices where one of them
> has a 32bit prefmem bar:  The (single) prefmem memory window must be
> below 4G then too.
> 
> I think we'll have to keep track for each bar whenever we'll go map it
> above or below 4G.  For starters this logic can be simply to only map
> 64bit bars of root bus devices above 4G, which completely sidesteps the
> bridge issues for now.
> 
> Once qemu has full pci-e support we probably want refine this logic,
> which probably requires an extra pass between pci bar discovery and
> placing the bars into the memory regions we have.

I was looking at this last week, along with the coreboot PCI code.  I
think this could be done in four "passes" - first pass to find the
total size, minimum alignment, and maximum address of all resources
for all regular devices.  The second pass propagates this info to
bridges.  The third pass allocates the resources.  The fourth pass
assigns the resources to the devices.

The current code already effectively has these four "passes" - the
thing I think is missing is tracking the "maximum address" of
resources, propagating that to bridges, and assigning allocations
above 4G.

-Kevin