On 18/11/16 19:17, Andrea Bolognani wrote:
On Thu, 2016-11-17 at 13:02 +1100, Alexey Kardashevskiy wrote:
>> That said, considering that a big part of the PCI address
>> allocation logic is based off whether the specific machine
>> type exposes a legay PCI Root Bus or a PCI Express Root Bus,
>> libvirt will need a way to be able to tell which one is which.
>>
>> Version checks are pretty much out of the question, as they
>> fail as soon as downstream releases enter the picture. A
>> few ways we could deal with the situation:
>>
>> 1) switch to PCI Express on newer machine types, and
>> expose some sort of capability through QMP so that
>> libvirt can know about the switch
[...]
>> Option 1) would break horribly with existing libvirt
>> versions, and so would Option 2) if we default to using
>
> How exactly 1) will break libvirt? Migrating from pseries-2.7 to
> pseries-2.8 does not work anyway, and machines are allowed to behave
> different from version to version, what distinct difference will using
> "pseries-pcie-X.Y" make?
Existing libvirt versions assume that pseries guests have
If libvirt is using just "pseries" (without a version), then having a
virtual PCIe-PCI bridge (and "pci.0" always available by default) will do it.
If libvirt is using a specific version of pseries, then it already knows
that <=2.7 has pci.0 as a root, pcie.0 otherwise. libvirt has a knowledge
what QEMU version has what, right?
In what scenario will an additional machine type help?
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.
So if you used a new QEMU binary with a libvirt version
that doesn't know about the change, new guests would end up
using the wrong controllers. Existing guests would not be
affected as they would stick with the older machine types,
of course.
> 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.
I do not know about i440<->q35 but in pseries the difference is going to be
very simple.
For example, we did not change the machine type when we switched from
default OHCI to XHCI, switching from PCI to PCIe does not sound like we
need a whole new machine type for this either.
Even if no newer pseries-x.y were to be added after
introducing pseries-pcie, you could still easily create
guests that use either root bus, so no loss in functionality.
I could do this with the existing pseries if the machine had a "root but
type" property.
--
Alexey