On Wed, 2016-11-23 at 16:00 +1100, David Gibson wrote:
> Existing libvirt versions assume that pseries guests have
> a legacy PCI root bus, and will base their PCI address
> allocation / PCI topology decisions on that fact: they
> will, for example, use legacy PCI bridges.
Um.. yeah.. trouble is libvirt's PCI-E address allocation probably
won't work for spapr PCI-E either, because of the weird PCI-E without
root complex presentation we get in PAPR.
So, would the PCIe Root Bus in a pseries guest behave
differently than the one in a q35 or mach-virt guest?
Does it have a different number of slots, do we have to
plug different controllers into them, ...?
Regardless of how we decide to move forward with the
PCIe-enabled pseries machine type, libvirt will have to
know about this so it can behave appropriately.
> > I believe after we introduced the very first
> > pseries-pcie-X.Y, we will just stop adding new pseries-X.Y.
>
> Isn't i440fx still being updated despite the fact that q35
> exists? Granted, there are a lot more differences between
> those two machine types than just the root bus type.
Right, there are heaps of differences between i440fx and q35, and
reasons to keep both updated. For pseries we have neither the impetus
nor the resources to maintain two different machine type variant,
where the only difference is between legacy PCI and weirdly presented
PCI-E.
Calling the PCIe machine type either pseries-2.8 or
pseries-pcie-2.8 would result in the very same amount of
work, and in both cases it would be understood that the
legacy PCI machine type is no longer going to be updated,
but can still be used to run existing guests.
--
Andrea Bolognani / Red Hat / Virtualization