On Fri, Nov 25, 2016 at 03:36:25PM +0100, Andrea Bolognani wrote: > 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. Yeah, but the latter basically just won't work. > 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. Right. And the general recomendation for PAPR guests is that each passed through device (or rather, each passed through iommu group) have a separate virtual PHB on the guest. With this rework libvirt could switch over to implementing that recommendation. > 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 > -- 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
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
