Book 1: A Journey Begins
========================

These commits merely set the stage for what's coming next.
Adventure! Challenges! Friendship! Perhaps even love?

  00-03: Trivial cleanups
  04-05: Test suite changes that will make implementing
         future test cases possible; get them out of the
         way early in order to make patches more
         straightforward when the time finally comes
     06: Simple is beautiful


Book 2: From Great POWERs
=========================

Our hero faces and overcomes many hardships and by doing so
grows as an individual, but something is still amiss.

  07-09: Get ready to remove some assumptions...
     10: ... and then promptly remove them. Hashtag efficient
  11-17: Introduce new characters-I mean, XML elements and
         attributes and capabilities and all that jazz. Close
         enough, I say.
     18: By now, our hero has acquired amazing powers such as
         being able to create pSeries guests with multiple
         PHBs; unfortunately, he still has to rely on his
         strenght and his strength alone when facing new
         challenges. Wouldn't it be great if he could get
         some help? Maybe that's exactly where the story is
         heading, but we'll have to wait for the next books
         to find out...
     19: Prove to the world that the journey is more important
         than the destination, yet you still gotta get there
         at some point


Book 3: With a Little Help
==========================

Joined by a ragtag group of newfound friends, our hero can
push forward knowing that he will always be able to count
on their help, and that he'll never again be alone.

     20: You can only know how far you've come if you marked
         your starting point on the map
  21-22: The Evil One can only recoil in horror as its
         minions are banished from the land, one by one.
         Onwards to the final battle!


Book 4: The Parting of the Ways
===============================

Every journey must come to an end. The Evil One is at last
ready to set in motion its plan to take over the entire land;
our hero and his companions are the only obstacles standing
in its way. Will they be able to stop impending doom? Maybe,
but chances are sure stacked against them. Will knowing this
stop them from fighting until their last breath? Of course
not. Is the title a Doctor Who reference? You better believe
it is!

  23-25: More characters join the fray, as the narrative
         gears up for an epic finale
     26: The final battle takes place. Swords will clash,
         spells will be cast, old friends will fall, and
         when all is said and done... Well, you didn't
         really expect me to give away the ending so
         easily, did you? :)


Book 5: ???
===========

Whew, that was quite something, wasn't it? But wait, there's
more! The fifth book in this engrossing tetralogy is still
being drafted, but is meant to be published along with the
rest and provide insights and details that might have
escaped even the most attentive reader... Yes, I'm talking
about documentation here.


Hardcover and paperback editions available. Signed copies
can be purchased via mail order.


Andrea Bolognani (26):
  conf: Remove obsolete comment
  conf: Make virDomainPCIAddressSetGrow() private
  conf: Tweak virDomainPCIAddressGetNextAddr() signature
  tests: Update qemumemlock data
  tests: Mock IOMMU groups
  conf: Simplify slot allocation
  qemu: Allow qemuBuildControllerDevStr() to return NULL
  qemu: Tweak index number checking
  conf: Move index number checking to drivers
  qemu: Relax pci-root index requirement for pSeries guests
  schema: Allow <target index='...'/>
  conf: Parse and format <target index='...'/>
  schema: Allow 'spapr-pci-host-bridge' controller model
  conf: Add 'spapr-pci-host-bridge' controller model
  qemu: Automatically pick index and model for pci-root controllers
  qemu: Introduce QEMU_CAPS_DEVICE_SPAPR_PCI_HOST_BRIDGE
  qemu: Deal with PHB naming convention
  qemu: Use multiple PHBs for pSeries guests
  tests: Add tests for pSeries guests with multiple PHBs
  tests: Add baseline tests for automatic PHB usage
  qemu: Use PHBs to fill holes in PCI bus numbering
  qemu: Use PHBs when extending the guest PCI topology
  conf: Introduce isolation groups
  schema: Allow <isolationGroup/>
  conf: Parse and format <isolationGroup/>
  qemu: Isolate hostdevs on pSeries guests

 docs/schemas/domaincommon.rng                      |  12 ++
 src/bhyve/bhyve_device.c                           |   4 +-
 src/bhyve/bhyve_domain.c                           |  15 ++
 src/conf/device_conf.h                             |   8 +-
 src/conf/domain_addr.c                             | 138 +++++++--------
 src/conf/domain_addr.h                             |  28 +--
 src/conf/domain_conf.c                             |  50 +++++-
 src/conf/domain_conf.h                             |   6 +
 src/libvirt_private.syms                           |   1 -
 src/libxl/libxl_domain.c                           |  14 ++
 src/lxc/lxc_domain.c                               |  14 ++
 src/openvz/openvz_driver.c                         |  14 ++
 src/qemu/qemu_capabilities.c                       |   3 +
 src/qemu/qemu_capabilities.h                       |   3 +
 src/qemu/qemu_command.c                            | 146 +++++++++++++---
 src/qemu/qemu_command.h                            |   9 +-
 src/qemu/qemu_domain.c                             |  14 ++
 src/qemu/qemu_domain_address.c                     | 190 ++++++++++++++++++---
 src/qemu/qemu_hotplug.c                            |   5 +-
 src/uml/uml_driver.c                               |  14 ++
 src/vz/vz_driver.c                                 |  14 ++
 src/xen/xen_driver.c                               |  14 ++
 .../qemuargv2xmldata/qemuargv2xml-pseries-disk.xml |   5 +-
 .../qemuargv2xml-pseries-nvram.xml                 |   5 +-
 tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml  |   1 +
 .../qemumemlock-pc-hardlimit+hostdev.xml           |   2 +-
 .../qemumemlock-pc-hardlimit+locked+hostdev.xml    |   2 +-
 tests/qemumemlockdata/qemumemlock-pc-hostdev.xml   |   2 +-
 .../qemumemlock-pc-locked+hostdev.xml              |   2 +-
 .../qemumemlock-pseries-hardlimit+hostdev.xml      |   2 +-
 ...emumemlock-pseries-hardlimit+locked+hostdev.xml |   2 +-
 .../qemumemlock-pseries-hostdev.xml                |   2 +-
 .../qemumemlock-pseries-locked+hostdev.xml         |   2 +-
 tests/qemumemlocktest.c                            |  21 ++-
 .../qemuxml2argv-pseries-hostdev.args              |  25 +++
 .../qemuxml2argv-pseries-hostdev.xml               |  33 ++++
 .../qemuxml2argv-pseries-many-buses-1.args         |  22 +++
 .../qemuxml2argv-pseries-many-buses-1.xml          |  20 +++
 .../qemuxml2argv-pseries-many-buses-2.args         |  22 +++
 .../qemuxml2argv-pseries-many-buses-2.xml          |  18 ++
 .../qemuxml2argv-pseries-many-devices.args         |  53 ++++++
 .../qemuxml2argv-pseries-many-devices.xml          |  49 ++++++
 .../qemuxml2argv-pseries-phb-default-missing.args  |  22 +++
 .../qemuxml2argv-pseries-phb-default-missing.xml   |  16 ++
 .../qemuxml2argv-pseries-phb-simple.args           |  22 +++
 .../qemuxml2argv-pseries-phb-simple.xml            |  17 ++
 tests/qemuxml2argvtest.c                           |  51 +++++-
 .../qemuxml2xmlout-panic-pseries.xml               |   5 +-
 .../qemuxml2xmlout-ppc64-usb-controller-legacy.xml |   5 +-
 .../qemuxml2xmlout-ppc64-usb-controller.xml        |   5 +-
 .../qemuxml2xmlout-pseries-hostdev.xml             |  56 ++++++
 ...xml => qemuxml2xmlout-pseries-many-buses-1.xml} |  19 ++-
 ...xml => qemuxml2xmlout-pseries-many-buses-2.xml} |  20 ++-
 .../qemuxml2xmlout-pseries-many-devices.xml        | 125 ++++++++++++++
 .../qemuxml2xmlout-pseries-nvram.xml               |   5 +-
 .../qemuxml2xmlout-pseries-panic-missing.xml       |   5 +-
 .../qemuxml2xmlout-pseries-panic-no-address.xml    |   5 +-
 ...qemuxml2xmlout-pseries-phb-default-missing.xml} |  18 +-
 ...m.xml => qemuxml2xmlout-pseries-phb-simple.xml} |  18 +-
 tests/qemuxml2xmltest.c                            |  47 ++++-
 tests/virpcimock.c                                 |  43 ++++-
 61 files changed, 1306 insertions(+), 204 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-hostdev.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-hostdev.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-many-buses-1.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-many-buses-1.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-many-buses-2.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-many-buses-2.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-many-devices.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-many-devices.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-phb-default-missing.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-phb-default-missing.xml
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-phb-simple.args
 create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-pseries-phb-simple.xml
 create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pseries-hostdev.xml
 copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-pseries-nvram.xml => qemuxml2xmlout-pseries-many-buses-1.xml} (55%)
 copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-pseries-nvram.xml => qemuxml2xmlout-pseries-many-buses-2.xml} (54%)
 create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-pseries-many-devices.xml
 copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-pseries-nvram.xml => qemuxml2xmlout-pseries-phb-default-missing.xml} (56%)
 copy tests/qemuxml2xmloutdata/{qemuxml2xmlout-pseries-nvram.xml => qemuxml2xmlout-pseries-phb-simple.xml} (56%)

-- 
2.7.5

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Now for a slightly more serious overview; more details can
be obtained by reading the bug report[1].

There are two main goals behind this series:

  1) allow the use of multiple PHBs for pSeries guests;
  2) isolate hostdevs from emulated devices.

By implementing these changes, pSeries guests running on
QEMU/KVM become more similar to those running on PowerVM,
which is great for admins. It also makes it possible to
have better error detection / recovery.


The first part involves convincing libvirt that a guest
can have more than a single pci-root controller, which is
something that was explicitly forbidden until now. Only
pSeries guests get to follow the new rules, of course.

Once PHBs are usable, it makes sense to just use them
for pretty much everything on pSeries guests. pci-bridge
is no longer needed, which is good because it probably
never really worked on such guests.


To match PowerVM's behavior and provide better isolation,
hostdevs should be assigned each their own PHB. Well,
almost: the exact requirement is one PHB per host IOMMU
group, with the default PHB being reserved for emulated
devices.

To achieve this, the concept of "isolation group"[2] is
introduced: each PHB is assigned one, and only devices
that match it will be automatically assigned to that
PHB. For hostdevs, the isolation group is the same as
the host IOMMU group; emulated devices are assigned the
default isolation group, same as the default PHB. It all
works out.


The implementation is basically complete, minus the
documentation. I'm debating whether the current handling
of the default isolation group is good or not, but the
ideas are all there and I expect I'll need a couple of
respins to get all the details right, so feel free to
start reviewing :)


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1280542
[2] Named like that because, at least for me, "IOMMU" is
    basically a tongue twister
-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

If anyone's looking at this, please be aware that I'm in the
process of reworking Book 4 (eg. patches 23-26) quite heavily
at the moment in order to address a couple of limitations:
the lack of hotplug support, and the fact that isolation
groups are assigned in a way that's very static and as such
requires too much planning to be usable.

The goal is for isolation groups to be more dynamic while
still ensuring no conflicts can occur, so for example PHBs
will be allowed to change their isolation group if there
are no devices assigned to them.

I'm also experimenting to see whether we can get away with
not formatting <isolationGroup/> at all, and it looks like
it might just work.

Everything up until patch 22 should remain unchanged.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list