On Tue, Nov 22, 2016 at 01:26:49PM +1100, Alexey Kardashevskiy wrote:
On 22/11/16 00:08, Andrea Bolognani wrote:
On Mon, 2016-11-21 at 13:12 +1100, Alexey Kardashevskiy wrote:
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.
Please don't. Any device that is included in the guest by default and can't be turned off makes libvirt's life significantly more difficult (see below).
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?
It doesn't yet, that's the point :)
We *could* add such knowledge to libvirt[1], but *existing* libvirt versions would still not know about it, which means that upgrading QEMU withough upgrading libvirt will result in failure to create new guests.
In what scenario will an additional machine type help?
Because then libvirt could learn that
pseries-x.y <-> pci.0 pseries-pcie-x.y <-> pcie.0
the same way it already knows that
pc-i440fx-x.y <-> pci.0 pc-q35-x.y <-> pcie.0
and choosing between one or the other would be, I think, much easier for the user as well.
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.
The change from OHCI to XHCI only affected the *default* USB controller, which libvirt tries its best not to use anyway: instead, it will prefer to use '-M ...,usb=off' along with '-device ...' and set both the controller model and its PCI address explicitly, partially to shield its users from such changes in QEMU.
Ok. Always likes this approach really. We should start moving to this direction with PHB - stop adding the default PHB at all when -nodefaults is passed (or -machine pseries,pci=off ?) and let libvirt manage PHBs itself (and provide another spapr-phb type like spapr-pcie-host-bridge or add a "pcie_root_bus_type" property to the existing PHB type).
What will be wrong with this approach?
Hm, that's a good point. If were removing the default PHB entirely, that I would consider a possible case for a new machine type. Putting construction of the PHBs into libvirt's hand could make life simpler there. Although it would make it a bit of a pain for people starting qemu by hand. I think this option is worth some thought. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson