All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Greg Kurz <groug@kaod.org>,
	qemu-devel@nongnu.org, David Gibson <david@gibson.dropbear.id.au>
Cc: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	qemu-ppc@nongnu.org, Marcel Apfelbaum <marcel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] spapr/pci: populate PCI DT in reverse order
Date: Fri, 24 Feb 2017 11:51:33 +0100	[thread overview]
Message-ID: <d34307e3-6fcd-53bd-d134-5f9de21516d7@redhat.com> (raw)
In-Reply-To: <148776029578.5865.5785337570950575739.stgit@bahia>

On 22.02.2017 11:56, Greg Kurz wrote:
> From: Greg Kurz <gkurz@linux.vnet.ibm.com>
[...]
> 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.
[...]
> 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 for applying the patch.

During the past months, I've also run one or two times into issues with
the reversed ordering... fortunately, I was able to work around them (or
fix other bugs triggered by this), but I think it would be better to
return the the ascending order again to avoid further future problems.

 Thomas

  reply	other threads:[~2017-02-24 10:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-22 10:56 [Qemu-devel] [PATCH] spapr/pci: populate PCI DT in reverse order Greg Kurz
2017-02-24 10:51 ` Thomas Huth [this message]
2017-02-24 11:12 ` Nikunj A Dadhania
2017-02-25  9:39 ` Alexey Kardashevskiy
2017-02-25 10:40   ` Greg Kurz
2017-02-28  0:43     ` Alexey Kardashevskiy
2017-02-27 22:20 ` [Qemu-devel] [Qemu-ppc] " Greg Kurz
2017-03-01  1:07   ` David Gibson
2017-02-28  0:51 ` [Qemu-devel] " David Gibson
  -- strict thread matches above, loose matches on Subject: below --
2015-11-30 10:45 Greg Kurz
2015-12-01 21:48 ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d34307e3-6fcd-53bd-d134-5f9de21516d7@redhat.com \
    --to=thuth@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=nikunj@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.