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: 4566 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]