[SLOF] [PATCH] pci: walk through the PCI DT in reverse order

Greg Kurz gkurz at linux.vnet.ibm.com
Fri Nov 27 20:04:18 AEDT 2015


On Fri, 27 Nov 2015 10:57:17 +1100
David Gibson <david at gibson.dropbear.id.au> wrote:

> On Thu, Nov 26, 2015 at 08:26:50PM +0100, Thomas Huth wrote:
> > On 26/11/15 17:34, Greg Kurz wrote:
> > > With the same set of devices, if QEMU does not do the PCI Enumeration (old
> > > QEMU that doesn't set the qemu,phb-enumerated property), we get:
> > > 
> > > Populating /pci at 800000020000000
> > >  Adapters on 0800000020000000
> > >                      00 0800 (D) : 1af4 1000    virtio [ net ]
> > >                      00 1000 (D) : 106b 003f    serial bus [ usb-ohci ]
> > >                      00 1800 (D) : 1af4 1003    communication-controller*
> > >                      00 2000 (D) : 1af4 1001    virtio [ block ]
> > >                      00 2800 (D) : 1af4 1001    virtio [ block ]
> > >                      00 3000 (D) : 1af4 1001    virtio [ block ]
> > >                      00 3800 (D) : 1af4 1002    unknown-legacy-device*
> > > 
> > > but in the case of a newer QEMU, when SLOF walks through the DT, we get:
> > > 
> > > Populating /pci at 800000020000000
> > >                      00 3800 (D) : 1af4 1002    unknown-legacy-device*
> > >                      00 3000 (D) : 1af4 1001    virtio [ block ]
> > >                      00 2800 (D) : 1af4 1001    virtio [ block ]
> > >                      00 2000 (D) : 1af4 1001    virtio [ block ]
> > >                      00 1800 (D) : 1af4 1003    communication-controller*
> > >                      00 1000 (D) : 106b 003f    serial bus [ usb-ohci ]
> > >                      00 0800 (D) : 1af4 1000    virtio [ net ]
> > > 
> > > This is a confusing behaviour change for users. This patch fixes that: we
> > > push all the child nodes to the stack and configure them in reverse order.
> 
> Really?  I mean the change this causes in kernel discovery order I can
> see the problem with, although you're not supposed to depend on
> discovery order or default kernel naming.  Is the simple order of
> listing the devices really important?
> 

It means that the 'dev' attribute in <target> section in libvirt XML is
ultimately not working for pseries guests.

Since the libvirt documentation says "The actual device name specified is
not guaranteed to map to the device name in the guest OS. Treat it as a
device ordering hint.", I guess it is not so important.

> > With your patch, the output during boot is in the right order, but the
> > nodes in the device tree are still ordered wrong (type "dev /" and then
> > "ls" at the SLOF prompt).
> > Where does the wrong order come from? Is it QEMU who's doing this wrong
> > already? Then it should maybe be rather fixed there?
> 
> qemu did change the order things get emitted into the flattened tree
> (because fdt_add_subnode() adds to the front of the list of children)
> - but things are not supposed to rely on the order of things in the
> fdt.  If you care about order you're supposed to sort them yourself
> (on reg value, or whatever criterion makes sense).
> 



More information about the SLOF mailing list