Re: [PATCH] spapr_pci: Robustify support of PCI bridges

[Greg Kurz <groug@kaod.org>]

On Thu, 16 Jul 2020 16:23:52 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> David Gibson <david@gibson.dropbear.id.au> writes:
> 
> > On Thu, Jul 16, 2020 at 12:32:44PM +0200, Greg Kurz wrote:
> >> On Thu, 16 Jul 2020 14:45:40 +1000
> >> David Gibson <david@gibson.dropbear.id.au> wrote:
> >> 
> >> > On Thu, Jul 09, 2020 at 07:12:47PM +0200, Greg Kurz wrote:
> >> > > Some recent error handling cleanups unveiled issues with our support of
> >> > > PCI bridges:
> >> > > 
> >> > > 1) QEMU aborts when using non-standard PCI bridge types,
> >> > >    unveiled by commit 7ef1553dac "spapr_pci: Drop some dead error handling"
> >> > > 
> >> > > $ qemu-system-ppc64 -M pseries -device pcie-pci-bridge
> >> > > Unexpected error in object_property_find() at qom/object.c:1240:
> >> > > qemu-system-ppc64: -device pcie-pci-bridge: Property '.chassis_nr' not found
> >> > > Aborted (core dumped)
> >> > 
> >> > Oops, I thought we had a check that we actually had a "pci-bridge"
> >> > device before continuing with the hotplug, but I guess not.
> >> 
> >> Ah... are you suggesting we should explicitly check the actual type
> >> of the bridge rather than looking for the "chassis_nr" property ?
> >
> > Uh.. I thought about it, but I don't think it matters much which way
> > we do it.
> 
> Would it make sense to add the "chassis_nr" property to *all* PCI
> bridge devices?
> 

I see that the "PCI Express to PCI/PCI-X Bridge Specification" mentions
a "Chassis Number Register" which looks very similar to the what exists
in standard PCI-to-PCI brdiges. This doesn't seem to be implemented in
our "pcie-pci-bridge" device model though, but of course I have no idea
why :)

Maybe Michael or Marcel (cc'd) can share some thoughts about that ?

> [...]
>