On 07/23/2015 10:47 AM, John Ferlan wrote:
>
> 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!
It goes beyond that. Apparently you can hotplug an upstream, but it you
hotplug a downstream *into* the downstream the guest will never receive
any notification, so it's pointless - they are intended to be
hotpluggable, but only as a single unit, which we can't do with qemu's
interface.
It really is a huge maze of twisty passages, and I wouldn't understand
it *at all* without help from Alex. As it is, every day I find that I've
misunderstood something new.
>
>
>> </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..
why index=9 in particular? I suppose I could fill them all in in the
test, but just picked an arbitrary place to cut it off.
> 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.
You can't do that. a downstream port can only plug into an upstream
port. an upstream port can plug into either a downstream port or a root
port (but nothing else, which I didn't know until last week).
> Yes, I'm a visual learner ;-)
>
> I think having/using the xmlout would be beneficial too.
Not sure what you mean by that. Since the extra elements are
(necessarily) added after the parsing is all done, they don't show up in
the xmlout.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list