Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2807 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]