On Wed, 2016-11-23 at 16:02 +1100, David Gibson wrote: > > > 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. Note that libvirt always runs QEMU with -nodefaults, so we could just remove the default PHB if that flag is present, and leave it in if that's not the case. The idea itself sounds good, but of course it will require more work from the libvirt side than simply making the PCIe machine type behave like q35 and mach-virt. Moreover, we already have an RFE for supporting additional PHBs, we could solve both issues in one fell swoop and have the libvirt guest XML be a more faithful representation of the actual virtual hardware, which is always a win in my book. That will be even more important if it turns out that the rules for PCIe device assignment (eg. what device/controller can be plugged into which slot) are different for PCIe PHBs than they are for q35/mach-virt PCIe Root Bus. I've asked for clarifications about this elsewhere in the thread. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
