All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin O'Connor <kevin@koconnor.net>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	seabios@seabios.org, qemu-devel@nongnu.org,
	Gerd Hoffmann <kraxel@redhat.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>
Subject: Re: [Qemu-devel] [PATCH V2] pci: fixes to allow booting from extra root pci buses.
Date: Sun, 14 Jun 2015 17:59:55 -0400	[thread overview]
Message-ID: <20150614215955.GA6017@morn.localdomain> (raw)
In-Reply-To: <1434317958.3803.38.camel@kernel.crashing.org>

On Mon, Jun 15, 2015 at 07:39:18AM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2015-06-14 at 20:06 +0200, Michael S. Tsirkin wrote:
> 
> > > As I understand it, the use case for multiple PCI roots is large
> > > servers that process a lot of IO.
> > 
> > For better or worse, guest OS-es assume that numa locality
> > can only be specified for PCI roots.
> > 
> > So the use case is to specify numa locality for virtual
> > devices.
> 
> In addition, I'd add that on ppc "pseries", the standard way of
> hotplugging devices is to hotplug PCI roots (ie, a virtual host bridge
> with the new device(s) below it).  
> 
> > > I'm not aware of real world hardware with hot-plugable root buses.
> > > Should it come about then some kind of OS visible spec would be needed
> > > for the OS to identify and enumerate newly added buses, and I suppose
> > > we could figure out how to handle it once that type of thing happens.
> 
> On IBM ppc systems, both exist. IE, real HW hot pluggable roots (on
> older systems mostly, GX based drawers with PCI host bridges in them
> nowadays, we tend to use PCIe cable card based drawers), and in
> virtualized systems, hot plugging root bridges is the standard way
> PowerVM (aka pHyp) uses for hotplug which we need to support in
> qemu/pseries at some point.
> 
> > > > But more importantly, if the sort is by the bus number,
> > > > then how is it better than just using the bus number directly?
> 
> PCI Bus number makes no sense. Any root can have the whole range of bus
> numbers 0...255 and the bus number assignment is under control of the
> guest anyway. Or are you talking about a different bus number (somewhat
> picked up the conversation half way...)

There are x86 systems with multiple separate PCI root buses where one
can access the pci config space of all the buses using the same 0x0cf8
IO space.  During system setup, the multiple PCI root buses are each
configured to only respond to PCI config accesses within its range of
bus numbers.  So if "root1" is configured for bus ids between 64-128,
then it will only forward the request if the bus id in the request is
between 64-128.

I suspect in your PPC example that the separate root buses all had
separate io/memory space as well and thus were completely separate.
(That is, they don't share the equivalent of IO 0x0cf8.)  If so,
that's different from how the x86 qemu code and the x86 systems I was
discussing above work.

-Kevin

  reply	other threads:[~2015-06-14 22:00 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-11 13:37 [Qemu-devel] [PATCH V2] pci: fixes to allow booting from extra root pci buses Marcel Apfelbaum
2015-06-11 13:57 ` Laszlo Ersek
2015-06-11 13:58 ` Kevin O'Connor
2015-06-11 14:12   ` Marcel Apfelbaum
2015-06-11 14:24     ` Kevin O'Connor
2015-06-11 14:36       ` Marcel Apfelbaum
2015-06-11 15:00         ` Laszlo Ersek
2015-06-11 16:54         ` Kevin O'Connor
2015-06-11 17:46           ` Marcel Apfelbaum
2015-06-11 18:34             ` Laszlo Ersek
2015-06-11 19:24               ` Kevin O'Connor
2015-06-12  9:25                 ` Laszlo Ersek
2015-06-12 13:03                   ` Kevin O'Connor
2015-06-12 15:45                     ` Laszlo Ersek
2015-06-12 18:40                       ` Kevin O'Connor
2015-06-12 20:13                         ` Laszlo Ersek
2015-06-14 12:05                         ` Michael S. Tsirkin
2015-06-14 14:50                           ` Kevin O'Connor
2015-06-14 18:06                             ` Michael S. Tsirkin
2015-06-14 18:21                               ` Kevin O'Connor
2015-06-14 21:39                               ` Benjamin Herrenschmidt
2015-06-14 21:59                                 ` Kevin O'Connor [this message]
2015-06-15  2:50                                   ` Benjamin Herrenschmidt
2015-06-15  8:22                                     ` Michael S. Tsirkin
2015-06-11 19:10             ` Kevin O'Connor
2015-06-12  6:00               ` Gerd Hoffmann
2015-06-12 12:17                 ` Marcel Apfelbaum
2015-06-12 13:23                   ` Kevin O'Connor
2015-06-15  6:01                     ` Gerd Hoffmann
2015-06-15  6:50                       ` Gerd Hoffmann
2015-06-15  9:02                         ` Marcel Apfelbaum
2015-06-15  9:43                       ` Michael S. Tsirkin
2015-06-15 10:18                         ` Gerd Hoffmann
2015-06-15 10:26                           ` Michael S. Tsirkin
2015-06-11 14:35   ` Laszlo Ersek
2015-06-11 16:48     ` Kevin O'Connor
2015-06-11 18:38       ` [Qemu-devel] [SeaBIOS] " Laszlo Ersek
2015-06-14 12:10       ` [Qemu-devel] " Michael S. Tsirkin
2015-06-14 13:47         ` Kevin O'Connor

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=20150614215955.GA6017@morn.localdomain \
    --to=kevin@koconnor.net \
    --cc=benh@kernel.crashing.org \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=seabios@seabios.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.