From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9Psz-000600-Lx for qemu-devel@nongnu.org; Wed, 23 Nov 2016 00:14:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9Psv-000715-Em for qemu-devel@nongnu.org; Wed, 23 Nov 2016 00:14:21 -0500 Date: Wed, 23 Nov 2016 16:02:14 +1100 From: David Gibson Message-ID: <20161123050214.GE17795@umbus.fritz.box> References: <20161028120712.4a911866@bahia> <20161031025314.GJ18226@umbus.fritz.box> <20161101024634.GA14860@umbus.fritz.box> <1479218565.3319.18.camel@redhat.com> <3353ecef-2308-13e3-025d-df41b2e89945@ozlabs.ru> <1479457042.1391.11.camel@redhat.com> <1479733731.4367.4.camel@redhat.com> <98244c30-1397-5a1b-eb9a-446f41e9890e@ozlabs.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jTMWTj4UTAEmbWeb" Content-Disposition: inline In-Reply-To: <98244c30-1397-5a1b-eb9a-446f41e9890e@ozlabs.ru> Subject: Re: [Qemu-devel] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexey Kardashevskiy Cc: Andrea Bolognani , Greg Kurz , Paolo Bonzini , Alex Williamson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, libvir-list@redhat.com, Michael Roth --jTMWTj4UTAEmbWeb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 > >>>>> =20 > >>>>> [...] > >>>>> Option 1) would break horribly with existing libvirt > >>>>> versions, and so would Option 2) if we default to using > >>>> =20 > >>>> 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 usi= ng > >>>> "pseries-pcie-X.Y" make? > >>> =20 > >>> Existing libvirt versions assume that pseries guests have > >> =20 > >> 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. > >=20 > > 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 kno= ws > >> that <=3D2.7 has pci.0 as a root, pcie.0 otherwise. libvirt has a know= ledge > >> what QEMU version has what, right? > >=20 > > It doesn't yet, that's the point :) > >=20 > > 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. > > > >=20 > >> In what scenario will an additional machine type help? > >=20 > > Because then libvirt could learn that > >=20 > > pseries-x.y <-> pci.0 > > pseries-pcie-x.y <-> pcie.0 > >=20 > > the same way it already knows that > >=20 > > pc-i440fx-x.y <-> pci.0 > > pc-q35-x.y <-> pcie.0 > >=20 > > 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. > >>> =20 > >>> 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. > >>> =20 > >>>> I believe after we introduced the very first > >>>> pseries-pcie-X.Y, we will just stop adding new pseries-X.Y. > >>> =20 > >>> 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. > >> =20 > >> I do not know about i440<->q35 but in pseries the difference is going = to be > >> very simple. > >> =20 > >> 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. > >=20 > > 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=3Doff' along with > > '-device ...' and set both the controller model and its PCI > > address explicitly, partially to shield its users from such > > changes in QEMU. >=20 >=20 > 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=3Doff ?) and let libvirt manage PHBs itse= lf > (and provide another spapr-phb type like spapr-pcie-host-bridge or add a > "pcie_root_bus_type" property to the existing PHB type). >=20 > 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. --=20 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 --jTMWTj4UTAEmbWeb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYNSLWAAoJEGw4ysog2bOSmyUP/jnVDmATBNO/4qRhg/WEkkWR +fcSDzVdW5hNGgbOPijXMD4lagOWfpdsvxx9Yfh0NYns0ClqMzWrhy8zRsdg0yhT 5+RLrbmjwOxtavnRGxRE8P9ikJBhTJwQ1wGZJBhdTIdzC986uJPI6L3iiaIRVikT cF8nGNK3qEFjo+c7JvsvzBf6HFtXGnpUjeSc1C1trGYm5qQylJ6BRzVHcz11u5Cu RdyFC1YfSDlIY4WXfwxXMUjQ0Ox78gifuRkzTZhmwyfZOd4LT1IjR49qqCE3LJxb j11I0ocn253a0TIYpH2tFoZTy44Xx2JElJFL3uk6YFW/7Pyp6suqW2VC4PJ0yWxP yvewSW7/UWXCm14HEzDMrZZY1DREwRLKdH79TJloMAt4bnnW9LnrvaRItwap61wC QZ14dQ1eqPjEksrR0kU1h7Rfeu+th2azR58ta+a3i+KcelEZQuvJ8a/603uZGNXE exENVaSGLXxlVykb23NH0G3BdeC0j4iTOhpmJq4ENxpAUZswarDhrtPcd0lyToRJ Gt5rAUeDvc5NXt9p/Ij7muohb32VMLCcXtJbA2sZw9NK3h3r8/2vbkLaT5YYXkc9 9py4OU47/r+sOG4CLRrGXvnE6/ioDhyI7cqF+zvpqwutJn/EGzFAmuRzez2yHIM4 Bq1FRASMNaGBM0MtAZl3 =inpw -----END PGP SIGNATURE----- --jTMWTj4UTAEmbWeb--