[libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default
david at gibson.dropbear.id.au
Fri Dec 2 03:37:41 UTC 2016
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
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_!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the libvir-list