qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] spapr/pci: populate PCI DT in reverse order


From: Nikunj A Dadhania
Subject: Re: [Qemu-devel] [PATCH] spapr/pci: populate PCI DT in reverse order
Date: Fri, 24 Feb 2017 16:42:53 +0530
User-agent: Notmuch/0.21 (https://notmuchmail.org) Emacs/25.0.94.1 (x86_64-redhat-linux-gnu)

Greg Kurz <address@hidden> writes:

> From: Greg Kurz <address@hidden>
>
> Since commit 1d2d974244c6 "spapr_pci: enumerate and add PCI device tree", QEMU
> populates the PCI device tree in the opposite order compared to SLOF.
>
> Before 1d2d974244c6:
>
> Populating /address@hidden
>                      00 0000 (D) : 1af4 1000    virtio [ net ]
>                      00 0800 (D) : 1af4 1001    virtio [ block ]
>                      00 1000 (D) : 1af4 1009    virtio [ network ]
> Populating /address@hidden/address@hidden
>
> 7e5294b8 :  /address@hidden
> 7e52b998 :  |-- address@hidden
> 7e52c0c8 :  |-- address@hidden
> 7e52c7e8 :  +-- address@hidden ok
>
> Since 1d2d974244c6:
>
> Populating /address@hidden
>                      00 1000 (D) : 1af4 1009    virtio [ network ]
> Populating /address@hidden/address@hidden
>                      00 0800 (D) : 1af4 1001    virtio [ block ]
>                      00 0000 (D) : 1af4 1000    virtio [ net ]
>
> 7e5e8118 :  /address@hidden
> 7e5ea6a0 :  |-- address@hidden
> 7e5eadb8 :  |-- address@hidden
> 7e5eb4d8 :  +-- address@hidden ok
>
> This behaviour change is not actually a bug since no assumptions should be
> made on DT ordering. But it has no real justification either, other than
> being the consequence of the way fdt_add_subnode() inserts new elements
> to the front of the FDT rather than adding them to the tail.
>
> This patch reverts to the historical SLOF ordering by walking PCI devices
> in reverse order. This reconciles pseries with x86 machine types behavior.
> It is expected to make things easier when porting existing applications to
> power.
>
> Signed-off-by: Greg Kurz <address@hidden>
> Tested-by: Thomas Huth <address@hidden>
> Reviewed-by: Nikunj A Dadhania <address@hidden>
> (slight update to the changelog)
> Signed-off-by: Greg Kurz <address@hidden>
> ---
>  hw/pci/pci.c         |   28 ++++++++++++++++++++++++++++
>  hw/ppc/spapr_pci.c   |   12 ++++++------
>  include/hw/pci/pci.h |    4 ++++
>  3 files changed, 38 insertions(+), 6 deletions(-)
>
> David,
>
> This patch was posted and already discussed during 2.5 development:
>
> http://patchwork.ozlabs.org/patch/549925/
>
> The "consensus" at the time was that guests should not rely on device
> ordering (i.e. use persistent naming instead).
>
> I got recently contacted by OpenStack people who had several complaints
> about the reverse ordering of PCI devices in pseries: different behavior
> between ppc64 and x86, lots of time spent in debugging when porting
> applications from x86 to ppc64 before realizing that it is caused by the
> reverse ordering, necessity to carry hacky workarounds...
>
> One strong argument against handling this properly with persistent naming
> is that it requires systemd/udev. This option is considered as painful
> with CirrOS, which aims at remaining as minimal as possible and is widely
> used in the OpenStack ecosystem.
>
> Would you re-consider your position and apply this patch ?

+1

I was the one who introduced the reverse ordering inadvertently.

Regards
Nikunj




reply via email to

[Prev in Thread] Current Thread [Next in Thread]