All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laine Stump <laine@redhat.com>
To: qemu-devel@nongnu.org
Cc: Marcel Apfelbaum <marcel@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Laszlo Ersek <lersek@redhat.com>,
	mst@redhat.com, Peter Maydell <peter.maydell@linaro.org>,
	Drew Jones <drjones@redhat.com>,
	Andrea Bolognani <abologna@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines
Date: Wed, 7 Sep 2016 13:55:19 -0400	[thread overview]
Message-ID: <3ed4337a-f53a-a148-88d6-a3d35ffeca79@redhat.com> (raw)
In-Reply-To: <a8cdcccd-57de-b221-1162-3a7c7f137fa9@redhat.com>

On 09/07/2016 04:06 AM, Marcel Apfelbaum wrote:
> On 09/07/2016 09:21 AM, Gerd Hoffmann wrote:
>>   Hi,
>>
>>>>> ports, if that's allowed). For example:
>>>>>
>>>>> -  1-32 ports needed: use root ports only
>>>>>
>>>>> - 33-64 ports needed: use 31 root ports, and one switch with 2-32
>>>>> downstream ports
>>
>> I expect you rarely need any switches.  You can go multifunction with
>> the pcie root ports.  Which is how physical q35 works too btw, typically
>> the root ports are on slot 1c for intel chipsets:
>>
>> nilsson root ~# lspci -s1c
>> 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
>> Family PCI Express Root Port 1 (rev c4)
>> 00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
>> Family PCI Express Root Port 2 (rev c4)
>> 00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
>> Family PCI Express Root Port 3 (rev c4)
>>
>> Root bus has 32 slots, a few are taken (host bridge @ 00.0, lpc+sata @
>> 1f.*, pci bridge @ 1e.0, maybe vga @ 01.0), leaving 28 free slots.  With
>> 8 functions each you can have up to 224 root ports without any switches,
>> and you have not many pci bus numbers left until you hit the 256 busses
>> limit ...
>>
>
> Good point, maybe libvirt can avoid adding switches unless the user
> explicitly
> asked for them. I checked and it a actually works fine in QEMU.

I'm just now writing the code that auto-adds *-ports as they are needed, 
and doing it this way simplifies it *immensely*.

When I had to think about the possibility of needing upstream/downstream 
switches, as an endpoint device was added, I would need to check if a 
(root|downstream)-port was available and if not I might be able to just 
add a root-port, or I might have to add a downstream-port; if the only 
option was a downstream port, then *that* might require adding a new 
*upstream* port.

If I can limit libvirt to only auto-adding root-ports (and if there is 
no downside to putting multiple root ports on a single root bus port), 
then I just need to find an empty function of an empty slot on the root 
bus, add a root-port, and I'm done (and since 224 is *a lot*, I think at 
least for now it's okay to punt once they get past that point).

So, *is* there any downside to doing this?

  parent reply	other threads:[~2016-09-07 17:55 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-01 13:22 [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines Marcel Apfelbaum
2016-09-01 13:27 ` Peter Maydell
2016-09-01 13:51   ` Marcel Apfelbaum
2016-09-01 17:14     ` Laszlo Ersek
2016-09-05 16:24 ` Laszlo Ersek
2016-09-05 20:02   ` Marcel Apfelbaum
2016-09-06 13:31     ` Laszlo Ersek
2016-09-06 14:46       ` Marcel Apfelbaum
2016-09-07  6:21       ` Gerd Hoffmann
2016-09-07  8:06         ` Laszlo Ersek
2016-09-07  8:23           ` Marcel Apfelbaum
2016-09-07  8:06         ` Marcel Apfelbaum
2016-09-07 16:08           ` Alex Williamson
2016-09-07 19:32             ` Marcel Apfelbaum
2016-09-07 17:55           ` Laine Stump [this message]
2016-09-07 19:39             ` Marcel Apfelbaum
2016-09-07 20:34               ` Laine Stump
2016-09-15  8:38               ` Andrew Jones
2016-09-15 14:20                 ` Marcel Apfelbaum
2016-09-16 16:50                   ` Andrea Bolognani
2016-09-08  7:33             ` Gerd Hoffmann
2016-09-06 11:35   ` Gerd Hoffmann
2016-09-06 13:58     ` Laine Stump
2016-09-07  7:04       ` Gerd Hoffmann
2016-09-07 18:20         ` Laine Stump
2016-09-08  7:26           ` Gerd Hoffmann
2016-09-06 14:47     ` Marcel Apfelbaum
2016-09-07  7:53     ` Laszlo Ersek
2016-09-07  7:57       ` Marcel Apfelbaum
2016-10-04 14:59   ` Daniel P. Berrange
2016-10-04 15:40     ` Laszlo Ersek
2016-10-04 16:10       ` Laine Stump
2016-10-04 16:43         ` Laszlo Ersek
2016-10-04 18:08           ` Laine Stump
2016-10-04 18:52             ` Alex Williamson
2016-10-10 12:02               ` Andrea Bolognani
2016-10-10 14:36                 ` Marcel Apfelbaum
2016-10-11 15:37                   ` Andrea Bolognani
2016-10-04 18:56             ` Laszlo Ersek
2016-10-04 17:54         ` Laine Stump
2016-10-05  9:17           ` Marcel Apfelbaum
2016-10-10 11:09             ` Andrea Bolognani
2016-10-10 14:15               ` Marcel Apfelbaum
2016-10-11 13:30                 ` Andrea Bolognani
2016-10-04 15:45     ` Alex Williamson
2016-10-04 16:25       ` Laine Stump
2016-10-05 10:03         ` Marcel Apfelbaum
2016-09-06 15:38 ` Alex Williamson
2016-09-06 18:14   ` Marcel Apfelbaum
2016-09-06 18:32     ` Alex Williamson
2016-09-06 18:59       ` Marcel Apfelbaum
2016-09-07  7:44       ` Laszlo Ersek

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=3ed4337a-f53a-a148-88d6-a3d35ffeca79@redhat.com \
    --to=laine@redhat.com \
    --cc=abologna@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=drjones@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@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.