On 08/03/2015 06:23 AM, Martin Kletzander wrote: > On Sat, Jul 25, 2015 at 03:58:36PM -0400, 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). >> --- >> change for V2: >> * 1.3.0 -> 1.2.18 >> * possibly reworded documention a bit. >> >> docs/formatdomain.html.in | 49 >> +++++++++++++++------- >> docs/schemas/domaincommon.rng | 3 ++ >> src/conf/domain_addr.c | 11 +++++ >> src/conf/domain_conf.c | 6 ++- >> src/conf/domain_conf.h | 2 + >> src/qemu/qemu_command.c | 1 + >> .../qemuxml2argv-pcie-switch-downstream-port.xml | 44 >> +++++++++++++++++++ >> tests/qemuxml2xmltest.c | 1 + >> 8 files changed, 100 insertions(+), 17 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 d033542..2f61ac8 100644 >> --- a/docs/formatdomain.html.in >> +++ b/docs/formatdomain.html.in >> @@ -3030,11 +3030,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.2.18</span>) >> + 1.1.2</span>, pcie-root-port, pcie-switch-upstream-port, and >> + pcie-switch-downstream-port <span class="since">since >> 1.2.18</span>) > > s/18/19/ everywhere > >> diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c >> index 8bd4ac3..561d8cc 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: > > This could be merged with VIR_DOMAIN_CONTROLLER_MODEL_PCIE_ROOT_PORT, > what's the difference then? ACK if this is just a readability > enhancement and is supposed to be this way. It's that way because I didn't know for certain that there wouldn't be some difference between the two that needed to be accounted for (and at one point they were different, but that was due to my naive understanding of the differences between the different types of controllers). I noticed the similarity fairly late in the game, but forgot to do anything about it. I've now combined the two cases. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list