[libvirt] [PATCH 00/15] support for pxb and pxb-pcie controllers

Wed Mar 30 14:48:30 UTC 2016

On 03/30/2016 05:05 AM, Michal Privoznik wrote:
> On 24.03.2016 20:25, Laine Stump wrote:
>> These two controllers are used to create a new root bus on a 440fx
>> (pxb) or q35 (pxb-pie) virtual machine. There may be other use cases,
>> but the main reason for me taking the time to support a separate root
>> bus is to have assigned devices be visible in the guest on a different
>> NUMA node, so that the guest can be aware of the locality of the
>> device wrt CPU and memory that are on different NUMA nodes - although
>> you aren't required to, you can add a <node>N</node> subelement to the
>> bus' <target> element to indicate which NUMA node it is on (it's up to
>> the management application to place devices on that bus that really
>> are on the given NUMA node in the host).
>>
>> There are several differences between pxb and pxb-pcie, which are
>> detailed in the individual commit log messages, but in short:
>>
>> 1) pxb is for 440fx, pxb-pcie for q35 (they *might* work on other
>> arches/machinetypes that have a PCI or PCIe bus, but I haven't enabled
>> that)
>>
>> 2) pxb has an integrate d pci-bridge with 32 slots that are (should
>> be) hotplug-capable, while pxb-pcie supplies only a single slot, and
>> it will only accept a pcie-root-port (which will then accept a single
>> device, hotplug-capable) or a pcie-switch-upstream-port.
>>
>> Along the way I encountered a few minor problems/ugliness that I took
>> care of in patches 01/15 - 09/15. pxb support is in 10-12, and
>> pxb-pcie is in 13-15
>>
>> There is a bugzilla record associated with this:
>>
>>    https://bugzilla.redhat.com/show_bug.cgi?id=1103314
>>
>> Laine Stump (15):
>>    schema: make pci slot and function optional
>>    schema: rename uint8range/uint24range to uint8/uint24
>>    schema: new basic type - uint16
>>    schema: allow pci address attributes to be in decimal
>>    conf: use #define instead of literal for highest slot in upstream port
>>    conf: allow use of slot 0 in a dmi-to-pci-bridge
>>    conf/qemu: change the way VIR_PCI_CONNECT_TYPE_* flags work
>>    conf: utility function to convert PCI controller model into connect
>>      type
>>    qemu: set PCI controller default modelName in a separate function
>>    qemu: add capabilities bit for device "pxb"
>>    conf: new pci controller model pci-expander-bus
>>    qemu: support new pci controller model "pci-expander-bus"
>>    qemu: add capabilities bit for device "pxb-pcie"
>>    conf: new pci controller model pcie-expander-bus
>>    qemu: support new pci controller model "pcie-expander-bus"
>>
>>   docs/formatdomain.html.in                          |  74 +++-
>>   docs/schemas/basictypes.rng                        |  63 ++--
>>   docs/schemas/domaincommon.rng                      |  23 +-
>>   docs/schemas/networkcommon.rng                     |  12 +-
>>   docs/schemas/nwfilter.rng                          |  16 +-
>>   src/bhyve/bhyve_device.c                           |  10 +-
>>   src/conf/domain_addr.c                             | 119 +++++--
>>   src/conf/domain_addr.h                             |  68 ++--
>>   src/conf/domain_conf.c                             |  61 +++-
>>   src/conf/domain_conf.h                             |  11 +-
>>   src/libvirt_private.syms                           |   1 +
>>   src/qemu/qemu_capabilities.c                       |   4 +
>>   src/qemu/qemu_capabilities.h                       |   2 +
>>   src/qemu/qemu_command.c                            |  74 ++++
>>   src/qemu/qemu_domain.c                             |  42 +++
>>   src/qemu/qemu_domain_address.c                     | 305 +++++++++-------
>>   tests/qemucapabilitiesdata/caps_2.4.0-1.caps       |   1 +
>>   tests/qemucapabilitiesdata/caps_2.5.0-1.caps       |   1 +
>>   tests/qemucapabilitiesdata/caps_2.6.0-1.caps       |   2 +
>>   tests/qemucapabilitiesdata/caps_2.6.0-1.replies    |   3 +
>>   .../qemuxml2argv-aarch64-virtio-pci-default.args   |   2 +-
>>   ...l2argv-aarch64-virtio-pci-manual-addresses.args |   2 +-
>>   .../qemuxml2argv-pci-expander-bus-bad-machine.xml  | 167 +++++++++
>>   .../qemuxml2argv-pci-expander-bus-bad-node.xml     | 160 +++++++++
>>   .../qemuxml2argv-pci-expander-bus.args             |  87 +++++
>>   .../qemuxml2argv-pci-expander-bus.xml              | 167 +++++++++
>>   .../qemuxml2argv-pcie-expander-bus-bad-machine.xml |  36 ++
>>   .../qemuxml2argv-pcie-expander-bus.args            | 123 +++++++
>>   .../qemuxml2argv-pcie-expander-bus.xml             | 247 +++++++++++++
>>   .../qemuxml2argv-pcie-root-port.args               |   2 +-
>>   tests/qemuxml2argvdata/qemuxml2argv-pcie-root.args |   2 +-
>>   .../qemuxml2argv-pcie-switch-downstream-port.args  |   2 +-
>>   .../qemuxml2argv-pcie-switch-upstream-port.args    |   2 +-
>>   .../qemuxml2argv-pcihole64-q35.args                |   2 +-
>>   .../qemuxml2argv-q35-pm-disable-fallback.args      |   2 +-
>>   .../qemuxml2argv-q35-pm-disable.args               |   2 +-
>>   .../qemuxml2argv-q35-usb2-multi.args               |   2 +-
>>   .../qemuxml2argv-q35-usb2-reorder.args             |   2 +-
>>   tests/qemuxml2argvdata/qemuxml2argv-q35-usb2.args  |   2 +-
>>   tests/qemuxml2argvdata/qemuxml2argv-q35.args       |   2 +-
>>   .../qemuxml2argv-usb-controller-default-q35.args   |   2 +-
>>   .../qemuxml2argv-usb-controller-explicit-q35.args  |   2 +-
>>   tests/qemuxml2argvtest.c                           |  25 ++
>>   .../qemuxml2xmlout-aarch64-virtio-pci-default.xml  |   2 +-
>>   ...2xmlout-aarch64-virtio-pci-manual-addresses.xml |   2 +-
>>   .../qemuxml2xmlout-pci-expander-bus.xml            | 207 +++++++++++
>>   .../qemuxml2xmlout-pcie-expander-bus.xml           | 384 +++++++++++++++++++++
>>   .../qemuxml2xmlout-pcie-root-port.xml              |   2 +-
>>   .../qemuxml2xmlout-pcie-root.xml                   |   2 +-
>>   .../qemuxml2xmlout-pcie-switch-downstream-port.xml |   2 +-
>>   .../qemuxml2xmlout-pcie-switch-upstream-port.xml   |   2 +-
>>   .../qemuxml2xmlout-pcihole64-q35.xml               |   2 +-
>>   .../qemuxml2xmlout-q35-usb2-multi.xml              |   2 +-
>>   .../qemuxml2xmlout-q35-usb2-reorder.xml            |   2 +-
>>   .../qemuxml2xmloutdata/qemuxml2xmlout-q35-usb2.xml |   2 +-
>>   tests/qemuxml2xmloutdata/qemuxml2xmlout-q35.xml    |   2 +-
>>   tests/qemuxml2xmltest.c                            |  10 +
>>   57 files changed, 2296 insertions(+), 261 deletions(-)
>>   create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pci-expander-bus-bad-machine.xml
>>   create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pci-expander-bus-bad-node.xml
>>   create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pci-expander-bus.args
>>   create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pci-expander-bus.xml
>>   create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-expander-bus-bad-machine.xml
>>   create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-expander-bus.args
>>   create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pcie-expander-bus.xml
>>   create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pci-expander-bus.xml
>>   create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pcie-expander-bus.xml
>>
> ACK series.
>
> Unfortunately, this is after the freeze. So to obey the process we
> should not push this. But we broke the rule here and there. What's your
> opinion?
>

I mainly want to push it just to get it off my to-do list; there isn't 
any pressing schedule need for it. So rather than risk the embarrassment 
of a regression right before a release, I'll wait and push it after the 
release.

Thanks for the review!