From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fYRrV-0001Mh-Jf for qemu-devel@nongnu.org; Thu, 28 Jun 2018 04:01:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fYRrL-000797-Vz for qemu-devel@nongnu.org; Thu, 28 Jun 2018 04:01:05 -0400 Message-ID: From: Andrea Bolognani Date: Thu, 28 Jun 2018 10:00:49 +0200 In-Reply-To: <20180628035909.GE23134@umbus.fritz.box> References: <20180626135928.23950-1-clg@kaod.org> <7d5dbadc1bb62c40da5de76c2a02807b0b96e7c0.camel@redhat.com> <8a5d8ae0f382003f8fc2ebf9083c995177c90695.camel@redhat.com> <20180628035909.GE23134@umbus.fritz.box> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] ppc/pnv: Add model for Power8 PHB3 PCIe Host bridge List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: =?ISO-8859-1?Q?C=E9dric?= Le Goater , qemu-ppc@nongnu.org, qemu-devel@nongnu.org, Benjamin Herrenschmidt , Marcel Apfelbaum , "Michael S. Tsirkin" On Thu, 2018-06-28 at 13:59 +1000, David Gibson wrote: > On Wed, Jun 27, 2018 at 12:22:31PM +0200, Andrea Bolognani wrote: > > On Tue, 2018-06-26 at 19:02 +0200, C=C3=A9dric Le Goater wrote: > > > I didn't follow that discussion but this is "another" kind of PHB. > > > This one models the baremetal controller as found on OpenPOWER and > > > IBM Power machines. pSeries has a virtual PHB. > >=20 > > I understand that, and of course libvirt will need to learn about > > this new type of PHB and make sure both pSeries and PowerNV guests > > get the correct one assigned to them. >=20 > Hmm.. does it? I would have thought pnv could act more like x86, in > that libvirt doesn't attempt to create PHBs at all and just use the > ones that are built in. AFAIK x86 guests have a single PHB and additional ones cannot be created in any way, which means we don't have to do any additional second-guessing when assigning IDs to additional PCI controllers. > Though, come to that, I wouldn't think pnv support for libvirt would > be much of a priority anyway. The machine type is still very much in > flux, and it's designed primarily for testing and development, not > "real world" usage. Can you *guarantee* that someone won't ask for PowerNV support in libvirt at some point? Because if you can't (and I don't think you can ;) then this is still a valuable conversation to have. > > What I meant is that pSeries guests get a single PHB by default, > > with additional ones being instantiable through -device; this is > > also consistent with how PCI controllers are added to other guest > > types including pc, q35 and aarch64/virt, so it would be really > > nice if PowerNV behaved the same way. >=20 > Well.. sure.. but it doesn't. pSeries is a virtual platform, so we > have a reasonable amount of flexibility to define it as we want. > PowerNV is an emulation of existing hardware which has a specific > behaviour which we need to match. Sure, that's something to keep in mind. But the thing is, you still need to have *some* flexibility in the number of PHBs, since there is variation among real Power8 and Power9 chips; in the current incarnation, that flexibility is provided by the num_phbs parameter, which is an entirely new interface that's exclusive to PowerNV. What I'm suggesting is that the same amount of flexibility is offered through a standard interface, namely -device, instead. --=20 Andrea Bolognani / Red Hat / Virtualization