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
>
>
_______________________________________________
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
