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!
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list