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