From: Marcel Apfelbaum <marcel@redhat.com>
To: qemu-devel@nongnu.org
Cc: mst@redhat.com, lersek@redhat.com
Subject: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines
Date: Thu, 1 Sep 2016 16:22:07 +0300 [thread overview]
Message-ID: <1472736127-18137-1-git-send-email-marcel@redhat.com> (raw)
Proposes best practices on how to use PCIe/PCI device
in PCIe based machines and explain the reasoning behind them.
Signed-off-by: Marcel Apfelbaum <marcel@redhat.com>
---
Hi,
Please add your comments on what to add/remove/edit to make this doc usable.
Thanks,
Marcel
docs/pcie.txt | 145 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 145 insertions(+)
create mode 100644 docs/pcie.txt
diff --git a/docs/pcie.txt b/docs/pcie.txt
new file mode 100644
index 0000000..52a8830
--- /dev/null
+++ b/docs/pcie.txt
@@ -0,0 +1,145 @@
+PCI EXPRESS GUIDELINES
+======================
+
+1. Introduction
+================
+The doc proposes best practices on how to use PCIe/PCI device
+in PCIe based machines and explains the reasoning behind them.
+
+
+2. Device placement strategy
+============================
+QEMU does not have a clear socket-device matching mechanism
+and allows any PCI/PCIe device to be plugged into any PCI/PCIe slot.
+Plugging a PCI device into a PCIe device might not always work and
+is weird anyway since it cannot be done for "bare metal".
+Plugging a PCIe device into a PCI slot will hide the Extended
+Configuration Space thus is also not recommended.
+
+The recommendation is to separate the PCIe and PCI hierarchies.
+PCIe devices should be plugged only into PCIe Root Ports and
+PCIe Downstream ports (let's call them PCIe ports).
+
+2.1 Root Bus (pcie.0)
+=====================
+Plug only legacy PCI devices as Root Complex Integrated Devices
+even if the PCIe spec does not forbid PCIe devices. The existing
+hardware uses mostly PCI devices as Integrated Endpoints. In this
+way we may avoid some strange Guest OS-es behaviour.
+Other than that plug only PCIe Root Ports, PCIe Switches (upstream ports)
+or DMI-PCI bridges to start legacy PCI hierarchies.
+
+
+ pcie.0 bus
+ --------------------------------------------------------------------------
+ | | | |
+ ----------- ------------------ ------------------ ------------------
+ | PCI Dev | | PCIe Root Port | | Upstream Port | | DMI-PCI bridge |
+ ----------- ------------------ ------------------ ------------------
+
+2.2 PCIe only hierarchy
+=======================
+Always use PCIe Root ports to start a PCIe hierarchy. Use PCIe switches (Upstream
+Ports + several Downstream Ports) if out of PCIe Root Ports slots. PCIe switches
+can be nested until a depth of 6-7. Plug only PCIe devices into PCIe Ports.
+
+
+ pcie.0 bus
+ ----------------------------------------------------
+ | | |
+ ------------- ------------- -------------
+ | Root Port | | Root Port | | Root Port |
+ ------------ -------------- -------------
+ | |
+ ------------ -----------------
+ | PCIe Dev | | Upstream Port |
+ ------------ -----------------
+ | |
+ ------------------- -------------------
+ | Downstream Port | | Downstream Port |
+ ------------------- -------------------
+ |
+ ------------
+ | PCIe Dev |
+ ------------
+
+2.3 PCI only hierarchy
+======================
+Legacy PCI devices can be plugged into pcie.0 as Integrated Devices or
+into DMI-PCI bridge. PCI-PCI bridges can be plugged into DMI-PCI bridges
+and can be nested until a depth of 6-7. DMI-BRIDGES should be plugged
+only into pcie.0 bus.
+
+ pcie.0 bus
+ ----------------------------------------------
+ | |
+ ----------- ------------------
+ | PCI Dev | | DMI-PCI BRIDGE |
+ ---------- ------------------
+ | |
+ ----------- ------------------
+ | PCI Dev | | PCI-PCI Bridge |
+ ----------- ------------------
+ | |
+ ----------- -----------
+ | PCI Dev | | PCI Dev |
+ ----------- -----------
+
+
+
+3. IO space issues
+===================
+PCIe Ports are seen by Firmware/Guest OS as PCI bridges and
+as required by PCI spec will reserve a 4K IO range for each.
+The firmware used by QEMU (SeaBIOS/OVMF) will further optimize
+it by allocation the IO space only if there is at least a device
+with IO BARs plugged into the bridge.
+Behind a PCIe PORT only one device may be plugged, resulting in
+the allocation of a whole 4K range for each device.
+The IO space is limited resulting in ~10 PCIe ports per system
+if devices with IO BARs are plugged into IO ports.
+
+Using the proposed device placing strategy solves this issue
+by using only PCIe devices with PCIe PORTS. The PCIe spec requires
+PCIe devices to work without IO BARs.
+The PCI hierarchy has no such limitations.
+
+
+4. Hot Plug
+============
+The root bus pcie.0 does not support hot-plug, so Integrated Devices,
+DMI-PCI bridges and Root Ports can't be hot-plugged/hot-unplugged.
+
+PCI devices can be hot-plugged into PCI-PCI bridges. (There is a bug
+in QEMU preventing it to work, but it would be solved soon).
+The PCI hotplug is ACPI based and can work side by side with the PCIe
+native hotplug.
+
+PCIe devices can be natively hot-plugged/hot-unplugged into/from
+PCIe Ports (Root Ports/Downstream Ports). Switches are hot-pluggable.
+Keep in mind you always need to have at least one PCIe Port available
+for hotplug, the PCIe Ports themselves are not hot-pluggable.
+
+
+5. Device assignment
+====================
+Host devices are mostly PCIe and should be plugged only into PCIe ports.
+PCI-PCI bridge slots can be used for legacy PCI host devices.
+
+
+6. Virtio devices
+=================
+Virtio devices plugged into the PCI hierarchy or as an Integrated Devices
+will remain PCI and have transitional behaviour as default.
+Virtio devices plugged into PCIe ports are Express devices and have
+"1.0" behavior by default without IO support.
+In both case disable-* properties can be used to override the behaviour.
+
+
+7. Conclusion
+==============
+The proposal offers a usage model that is easy to understand and follow
+and in the same time overcomes some PCIe limitations.
+
+
+
--
2.5.5
next reply other threads:[~2016-09-01 13:22 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-01 13:22 Marcel Apfelbaum [this message]
2016-09-01 13:27 ` [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines 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
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=1472736127-18137-1-git-send-email-marcel@redhat.com \
--to=marcel@redhat.com \
--cc=lersek@redhat.com \
--cc=mst@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).