> Date: Fri, 14 Sep 2012 10:31:05 +0200
> From: Christian Ehrhardt <ehrha...@genua.de>
>
> Hi,
>
> On Thu, Sep 13, 2012 at 11:00:12PM +0200, Mark Kettenis wrote:
> > > However, there might be a different solution:
> > > We could track attached busses (not just host bridge busses but all
> > > busses)
> > > in the pci code (or via MD code and hooks but I think that would be a
> > > generic thing) and do nothing in pciattach if a bus is discovered for
> > > the second time.
> > >
> > > With this MD code could use whatever methods it wants to detect otherwise
> > > undiscovered host bridges. Possible methods might be magic numbers, hints
> > > from ACPI or even a linear scan of all possible bus numbers.
> > >
> > > Does this sound like a possible solution?
> >
> > It actually got me thinking about proper bus number resource
> > accounting again. Something that's needed for properly hot-plugging
> > pci busses. Below is a diff that does this.
> >
> > With that code, your acpi code can just try to grab the bus number
> > using extent_alloc_region() and only attach a bus if that succeeds.
>
> Nice idea!
>
> However, I have some doubts about the implementation. In particular
> you don't pass sc_busex down through bridge devices. This is ok as long
> as all busses that we _discover_ downstream of that bridge are in fact
> _physically_ dowstream of that bridge, too. In this case the bus range
> of the bridge (PPB_BUSINFO_SECONDARY..PPB_BUSINFO_SUBORDINATE) covers
> all busses.
Indeed. At some point I'll probably add extents for the secondary
busses as well, but they're not necessary for what you need.
> However, host bridges that are handled e.g. in arch/i386/pci/pchb.c
> can appear downstream of another bridge but use bus numbers that are
> outside of the upstream bridge's bus number range.
Right. That's easy to fix though. See the attached diff.
> The easiest solution would probably be, to make the pcibus_ex an MI
> thing, i.e. define and allocate it globally in dev/pci/pci.c.
No that's not acceptable. On real server hardware (not the glorified
PCs you're hacking on ;)) there are multiple, fully independent, PCI
host bridges serving independent PCI domains that each have the full
range of bus numbers available to them. Having a single global extent
obviously wouldn't work there.
Let me know if this works for you.
Index: pchb.c
===================================================================
RCS file: /cvs/src/sys/arch/i386/pci/pchb.c,v
retrieving revision 1.85
diff -u -p -r1.85 pchb.c
--- pchb.c 31 Aug 2010 17:13:46 -0000 1.85
+++ pchb.c 14 Sep 2012 17:45:46 -0000
@@ -409,6 +409,7 @@ pchbattach(struct device *parent, struct
pba.pba_iot = pa->pa_iot;
pba.pba_memt = pa->pa_memt;
pba.pba_dmat = pa->pa_dmat;
+ pba.pba_busex = pa->pa_busex;
pba.pba_domain = pa->pa_domain;
pba.pba_bus = pbnum;
pba.pba_pc = pa->pa_pc;
@@ -502,6 +503,7 @@ pchb_amd64ht_attach(struct device *self,
pba.pba_iot = pa->pa_iot;
pba.pba_memt = pa->pa_memt;
pba.pba_dmat = pa->pa_dmat;
+ pba.pba_busex = pa->pa_busex;
pba.pba_domain = pa->pa_domain;
pba.pba_bus = AMD64HT_LDT_SEC_BUS_NUM(bus);
pba.pba_pc = pa->pa_pc;
