[libvirt] [PATCHv2 16/17] conf: new pcie-controller model "pcie-switch-downstream-port"
John Ferlan
jferlan at redhat.com
Thu Jul 23 14:47:59 UTC 2015
On 07/17/2015 02:43 PM, Laine Stump wrote:
> This controller can be connected only to a port on a
> pcie-switch-upstream-port. It provides a single hotpluggable port that
> will accept any PCI or PCIe device, as well as any device requiring a
> pcie-*-port (the only current example of such a device is the
> pcie-switch-upstream-port).
> ---
> V2:
>
> * change test case to reflect additional pcie-root-port between
> pcie-root and pcie-switch-upstream-port and add a 2nd switch that is
> connected to a downstream port of the 1st switch.
>
> docs/formatdomain.html.in | 51 ++++++++++++++--------
> docs/schemas/domaincommon.rng | 3 ++
> src/conf/domain_addr.c | 11 +++++
> src/conf/domain_conf.c | 3 +-
> src/conf/domain_conf.h | 1 +
> src/qemu/qemu_command.c | 1 +
> .../qemuxml2argv-pcie-switch-downstream-port.xml | 44 +++++++++++++++++++
> tests/qemuxml2xmltest.c | 1 +
> 8 files changed, 95 insertions(+), 20 deletions(-)
> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-switch-downstream-port.xml
>
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index eb5b9b7..c2023d0 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -3025,11 +3025,12 @@
> PCI controllers have an optional <code>model</code> attribute with
> possible values <code>pci-root</code>, <code>pcie-root</code>,
> <code>pcie-root-port</code>, <code>pci-bridge</code>,
> - <code>dmi-to-pci-bridge</code>, or <code>pcie-switch-upstream-port</code>.
> + <code>dmi-to-pci-bridge</code>, <code>pcie-switch-upstream-port</code>, or
> + <code>pcie-switch-downstream-port</code>.
> (pci-root and pci-bridge <span class="since">since 1.0.5</span>,
> pcie-root and dmi-to-pci-bridge <span class="since">since
> - 1.1.2</span>, pcie-root-port and
> - pcie-switch-upstream-port <span class="since">since 1.3.0</span>)
> + 1.1.2</span>, pcie-root-port, pcie-switch-upstream-port, and
> + pcie-switch-downstream-port <span class="since">since 1.3.0</span>)
1.2.18
> The root controllers (<code>pci-root</code> and <code>pcie-root</code>)
> have an optional <code>pcihole64</code> element specifying how big
> (in kilobytes, or in the unit specified by <code>pcihole64</code>'s
> @@ -3074,8 +3075,8 @@
> </dd>
> <dt><code>chassis</code></dt>
> <dd>
> - pcie-root-port controllers can also have
> - a <code>chassis</code> attribute in
> + pcie-root-port and pcie-switch-downstream-port controllers can
> + also have a <code>chassis</code> attribute in
> the <code><model></code> subelement, which is used to
> control QEMU's "chassis" option for the device (normally
> libvirt automatically sets this to the same value as the index
> @@ -3083,13 +3084,13 @@
> </dd>
> <dt><code>port</code></dt>
> <dd>
> - pcie-root-port controllers can also have a <code>port</code>
> - attribute in the <code><model></code> subelement, which
> - is used to control QEMU's "port" option for the device
> - (normally libvirt automatically sets this based on the PCI
> - address where the root port is connected using the formula
> - (slot << 3) + function (although this could change in
> - the future).
> + pcie-root-port and pcie-switch-downstream-port controllers can
> + also have a <code>port</code> attribute in
> + the <code><model></code> subelement, which is used to
> + control QEMU's "port" option for the device (normally libvirt
> + automatically sets this based on the PCI address where the
> + root port is connected using the formula (slot << 3) +
> + function (although this could change in the future).
> </dd>
> </dl>
> <p>
> @@ -3139,14 +3140,26 @@
> </p>
> <p>
> Domains with an implicit pcie-root can also add controllers
> - with <code>model='pcie-root-port'</code>. This is a simple type of
> - bridge device that can connect only to one of the 31 slots on
> - the pcie-root bus on its upstream side, and makes a single
> - (PCIe, hotpluggable) port (at slot='0') available on the
> - downstream side. This controller can be used to provide a single
> - slot to later hotplug a PCIe device (but is not itself
> + with <code>model='pcie-root-port'</code>,
> + <code>model='pcie-switch-upstream-port'</code>,
> + and <code>model='pcie-switch-downstream-port'</code>. pcie-root-port
> + is a simple type of bridge device that can connect only to one
> + of the 31 slots on the pcie-root bus on its upstream side, and
> + makes a single (PCIe, hotpluggable) port (at slot='0') available
> + on the downstream side. This controller can be used to provide a
> + single slot to later hotplug a PCIe device (but is not itself
> hotpluggable - it must be in the configuration when the domain
> - is started). (<span class="since">since 1.3.0</span>)
> + is started). pcie-switch-upstream-port is a more flexible (but
> + also more complex) device that can only plug into a
> + pcie-root-port or pcie-switch-downstream-port on the upstream
> + side, and provides 32 ports on the downstream side (slot='0' -
> + slot='31') that accept only pcie-switch-downstream-port devices;
> + each pcie-switch-downstream-port device can only plug into a
> + pcie-switch-upstream-port on its upstream side, and on its
> + downstream side provides a single hotpluggable pcie port that
> + can accept any standard pci or pcie device (or another
> + pcie-switch-upstream-port). (<span class="since">since
> + 1.3.0</span>)
1.2.18
The upstream-port discussion from the previous patch will/should flow
into this I assume.
The whole hotplug conversation is really confusing - upstream/
downstream what can plug into what and when - my eyes are rolling around
in circles.
The upstream cannot be hotplugged into; however, the downstream has one
port that can be hotplugged. The downstream can only connect into the
upstream and the upstream can connect either into a downstream or a
root-port, but itself isn't hotpluggable. So hot plugging one into a
downstream still means one cannot hotplug anything into that upstream
device. A downstream device cannot plug into a root-port. I can only
hope I got that right ;-). I think I need one of the pile higher and
deeper degrees!
> </p>
> <pre>
> ...
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index 8b2f29c..f465ec4 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -1743,6 +1743,8 @@
> <value>ioh3420</value>
> <!-- implementations of 'pcie-switch-upstream-port' -->
> <value>x3130-upstream</value>
> + <!-- implementations of 'pcie-switch-downstream-port' -->
> + <value>xio3130-downstream</value>
> </choice>
> </attribute>
> <empty/>
> @@ -1790,6 +1792,7 @@
> <value>dmi-to-pci-bridge</value>
> <value>pcie-root-port</value>
> <value>pcie-switch-upstream-port</value>
> + <value>pcie-switch-downstream-port</value>
> </choice>
> </attribute>
> </group>
> diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
> index e40a66c..40ee659 100644
> --- a/src/conf/domain_addr.c
> +++ b/src/conf/domain_addr.c
> @@ -213,6 +213,17 @@ virDomainPCIAddressBusSetModel(virDomainPCIAddressBusPtr bus,
> bus->minSlot = 0;
> bus->maxSlot = 31;
> break;
> + case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
> + /* provides one slot which is pcie, can be used by devices
> + * that must connect to some type of "pcie-*-port", and
> + * is hotpluggable
> + */
> + bus->flags = VIR_PCI_CONNECT_TYPE_PCIE
> + | VIR_PCI_CONNECT_TYPE_PCIE_PORT
> + | VIR_PCI_CONNECT_HOTPLUGGABLE;
> + bus->minSlot = 0;
> + bus->maxSlot = 0;
> + break;
> default:
> virReportError(VIR_ERR_INTERNAL_ERROR,
> _("Invalid PCI controller model %d"), model);
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 4eeaa84..adf0af4 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -326,7 +326,8 @@ VIR_ENUM_IMPL(virDomainControllerModelPCI, VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST,
> "pci-bridge",
> "dmi-to-pci-bridge",
> "pcie-root-port",
> - "pcie-switch-upstream-port")
> + "pcie-switch-upstream-port",
> + "pcie-switch-downstream-port")
>
> VIR_ENUM_IMPL(virDomainControllerModelSCSI, VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LAST,
> "auto",
> diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> index b49c803..94b71bc 100644
> --- a/src/conf/domain_conf.h
> +++ b/src/conf/domain_conf.h
> @@ -754,6 +754,7 @@ typedef enum {
> VIR_DOMAIN_CONTROLLER_MODEL_DMI_TO_PCI_BRIDGE,
> VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT,
> VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_UPSTREAM_PORT,
> + VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT,
>
> VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST
> } virDomainControllerModelPCI;
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index 30f54ce..e3f0663 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -2291,6 +2291,7 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
> if (!options->type)
> deviceName = "x3130-upstream";
> break;
> + case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_SWITCH_DOWNSTREAM_PORT:
> case VIR_DOMAIN_CONTROLLER_MODEL_PCI_ROOT:
> case VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT:
> case VIR_DOMAIN_CONTROLLER_MODEL_PCI_LAST:
Based one what I see in the next patch, the index=9 upstream isn't
used.. Perhaps would be nice to show it's use in some way. May also be
useful to show a downstream plugged into a pcie-root-port and how that's
used. Yes, I'm a visual learner ;-)
I think having/using the xmlout would be beneficial too.
John
> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-pcie-switch-downstream-port.xml b/tests/qemuxml2argvdata/qemuxml2argv-pcie-switch-downstream-port.xml
> new file mode 100644
> index 0000000..ab32d44
> --- /dev/null
> +++ b/tests/qemuxml2argvdata/qemuxml2argv-pcie-switch-downstream-port.xml
> @@ -0,0 +1,44 @@
> +<domain type='qemu'>
> + <name>q35-test</name>
> + <uuid>11dbdcdd-4c3b-482b-8903-9bdb8c0a2774</uuid>
> + <memory unit='KiB'>2097152</memory>
> + <currentMemory unit='KiB'>2097152</currentMemory>
> + <vcpu placement='static' cpuset='0-1'>2</vcpu>
> + <os>
> + <type arch='x86_64' machine='q35'>hvm</type>
> + <boot dev='hd'/>
> + </os>
> + <clock offset='utc'/>
> + <on_poweroff>destroy</on_poweroff>
> + <on_reboot>restart</on_reboot>
> + <on_crash>destroy</on_crash>
> + <devices>
> + <emulator>/usr/libexec/qemu-kvm</emulator>
> + <disk type='block' device='disk'>
> + <source dev='/dev/HostVG/QEMUGuest1'/>
> + <target dev='sda' bus='sata'/>
> + <address type='drive' controller='0' bus='0' target='0' unit='0'/>
> + </disk>
> + <controller type='pci' index='0' model='pcie-root'/>
> + <controller type='pci' index='1' model='dmi-to-pci-bridge'/>
> + <controller type='pci' index='2' model='pci-bridge'/>
> + <controller type='pci' index='3' model='pcie-root-port'/>
> + <controller type='pci' index='4' model='pcie-switch-upstream-port'/>
> + <controller type='pci' index='5' model='pcie-switch-downstream-port'/>
> + <controller type='pci' index='6' model='pcie-switch-downstream-port'/>
> + <controller type='pci' index='7' model='pcie-switch-downstream-port'/>
> + <controller type='pci' index='8' model='pcie-switch-downstream-port'>
> + <model type='xio3130-downstream'/>
> + <target chassis='30' port='0x27'/>
> + </controller>
> + <controller type='pci' index='9' model='pcie-switch-upstream-port'/>
> + <controller type='pci' index='10' model='pcie-switch-downstream-port'/>
> + <controller type='pci' index='11' model='pcie-switch-downstream-port'/>
> + <controller type='pci' index='12' model='pcie-switch-downstream-port'/>
> + <controller type='sata' index='0'/>
> + <video>
> + <model type='qxl' ram='65536' vram='32768' vgamem='8192' heads='1'/>
> + </video>
> + <memballoon model='none'/>
> + </devices>
> +</domain>
> diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c
> index 80686ae..d5a565f 100644
> --- a/tests/qemuxml2xmltest.c
> +++ b/tests/qemuxml2xmltest.c
> @@ -569,6 +569,7 @@ mymain(void)
> DO_TEST_DIFFERENT("q35");
> DO_TEST("pcie-root-port");
> DO_TEST("pcie-switch-upstream-port");
> + DO_TEST("pcie-switch-downstream-port");
>
> DO_TEST("hostdev-scsi-lsi");
> DO_TEST("hostdev-scsi-virtio-scsi");
>
More information about the libvir-list
mailing list