On Wed, Jul 19, 2017 at 05:14:41PM +0000, Alexander Bezzubikov wrote:
> ср, 19 июля 2017 г. в 16:57, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
>
> > On Wed, Jul 19, 2017 at 04:20:12PM +0300, Aleksandr Bezzubikov wrote:
> > > Now PCI bridges (and PCIE root port too) get a bus range number in
> > system init,
> > > basing on currently plugged devices. That's why when one wants to
> > hotplug another bridge,
> > > it needs his child bus, which the parent is unable to provide.
> >
> > Could you explain how you trigger this?
>
>
> I'm trying to hot plug pcie-pci bridge into pcie root port, and Linux says
> 'cannot allocate bus number for device bla-bla'. This obviously does not
> allow me to use the bridge at all.
>
> >
> >
> > > The suggested workaround is to have vendor-specific capability in RedHat
> > generic pcie-root-port
> > > that contains number of additional bus to reserve on BIOS PCI init.
> >
> > But wouldn't the proper fix be for the PCI bridge to have the subordinate
> > value be extended to fit more bus ranges?
>
>
> What do you mean? This is what I'm trying to do. Do you suppose to get rid
> of vendor-specific cap and use original register value instead of it?
I would suggest a simple fix - each bridge has a a number of bus devices
it can use. You have up to 255 - so you split the number of northbridge
numbers by the amount of NUMA nodes (if that is used) - so for example
if you have 4 NUMA nodes, each bridge would cover 63 bus numbers.
Meaning the root bridge would cover 0->63 bus, 64->128, and so on.
That gives you enough space to plug in your plugged in devices
(up to 63).
And if you need sub-briges then carve out a specific range.
>
> >
> > >
> > > Aleksandr Bezzubikov (2):
> > > pci: add support for direct usage of bdf for capability lookup
> > > pci: enable RedHat pci bridges to reserve more buses
> > >
> > > src/fw/pciinit.c | 12 ++++++++++--
> > > src/hw/pcidevice.c | 24 ++++++++++++++++++++++++
> > > src/hw/pcidevice.h | 1 +
> > > 3 files changed, 35 insertions(+), 2 deletions(-)
> > >
> > > --
> > > 2.7.4
> > >
> > >
> >
> --
> Alexander Bezzubikov