[SeaBIOS] [PATCH 2/2] fw/pci: map memory and IO regions for multiple pci root buses

[Marcel Apfelbaum]

On Mon, 2014-11-24 at 15:28 +0100, Gerd Hoffmann wrote:
> On Mo, 2014-11-24 at 15:38 +0200, Marcel Apfelbaum wrote:
> > On Mon, 2014-11-24 at 13:28 +0100, Gerd Hoffmann wrote:
> > > On Mo, 2014-11-24 at 11:47 +0200, Marcel Apfelbaum wrote:
> > > > Removed the assumption that the system has only one primary root bus.
> > > > When mapping memory and IO regions go over all buses, skipping
> > > > secondary and absent buses.
> > > 
> > Hi Gerd,
> > Thanks for the review.
> > 
> > > I guess there are qemu patches adding support for multiple pci busses
> > > somewhere?
> > Yes, an RFC will be released soon on QEMU mailing list,
> > is a work in progress and I am currently trying to decide
> > if I wait for a fully functional series or release is sooner
> > for comments.
> 
> Early rfc would be good I guess.  First I have something to play with
> when looking closer at this patch series ;)
> 
> Second I suspect there might be some non-trivial interactions with acpi
> (pci region declaration), so early review is probably helpful to make
> sure the design goes into the right direction.

Got it! Sending the RFC soon :)

> 
> > > Hmm, that assigns the io regions in bus order.  I think it would be
> > > better to integrate this with the packing logic we already have:
> > > regions are sorted by size for best packing.  Regions behind pci bridges
> > > are grouped together.  I think we could group regions belonging to a pci
> > > bus in a simliar way.
> > You are right, but only partial. Let me explain (as I understand it).
> > The devices IO regions behind the bus are *already* packed (sorted by size).
> > The buses themselves are indeed not sorted by their total IO space.
> > The same is happening in pci_bios_init_root_regions_mem with the MMIO regions.
> > 
> > It seems that what I have to do is simply replace the current bus enumeration:
> > 	for (i = 0; i <= MaxPCIBus; i++) {
> > with one that goes over the sorted list of buses in decreasing order of their
> > total mem/IO consumed.
> > 
> > Do you agree?
> 
> I think I would try to reuse the existing code which does the same for
> bridges.  Reuse "struct pci_bus" to add one more level (and maybe rename
> the struct), then have the resource propagation code in
> pci_bios_check_devices() do the job.
Thanks for the idea. I'll try following it.

> 
> That will need some reorganization, because the simple "struct pci_bus
> *busses" array indexed by bus number will not work any more.  But I
> think that should be done nevertheless.  Your patch numbers all busses
> across pci domains incrementally.  Which I think is not how pci busses
> are numbered, I think each pci domain has its private bus number
> namespace.

The solution does not cover multiple domains. It only covers multiple
root buses in the default domain. (and this is what I am interested in)

The operating systems can support multiple pci root buses in the same domain like this:
   - The BIOS assigns for each pci primary bus a range from 0x0 to 0xff.
   - The ACPI tables inform the OS the bus ranges for each primary bus.
     (and the IO/mem ranges for each, of course)

The current code uses the busses array indexed by bus number (as you said).
Patch 1/2 leverages that by creating separate ranges for each primary bus.
Let's say we have 2 primary buses having numbers 0 and 10, each with 2 bridges.
The existing code will give range 1-2-3 to first primary bus and 10-11-12 to the second one.

You are right, seeing the QEMU RFC for it it will make more sense. I'll get to it. 

Thanks,
Marcel

> 
> cheers,
>   Gerd
> 
>