From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uhtdf-0006rt-Bw for qemu-devel@nongnu.org; Wed, 29 May 2013 23:35:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhtdX-000719-CK for qemu-devel@nongnu.org; Wed, 29 May 2013 23:34:55 -0400 Received: from ozlabs.org ([203.10.76.45]:55851) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhtdW-00070w-Ps for qemu-devel@nongnu.org; Wed, 29 May 2013 23:34:47 -0400 Date: Thu, 30 May 2013 13:34:41 +1000 From: David Gibson Message-ID: <20130530033441.GL5489@boomeroo.fritz.box> References: <1368059472-25071-1-git-send-email-david@gibson.dropbear.id.au> <1368059472-25071-7-git-send-email-david@gibson.dropbear.id.au> <20130523112230.GE17480@redhat.com> <20130523121627.GC26259@boomeroo.fritz.box> <20130529094341.GG5489@boomeroo.fritz.box> <20130529095553.GN4472@redhat.com> <20130529100642.GJ5489@boomeroo.fritz.box> <20130529101713.GP4472@redhat.com> <20130529110400.GK5489@boomeroo.fritz.box> <20130529122229.GS4472@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/ZYM6PqDyfNytx60" Content-Disposition: inline In-Reply-To: <20130529122229.GS4472@redhat.com> Subject: Re: [Qemu-devel] [PATCH 6/8] pci: Simpler implementation of primary PCI bus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, David Gibson --/ZYM6PqDyfNytx60 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 29, 2013 at 03:22:29PM +0300, Michael S. Tsirkin wrote: > On Wed, May 29, 2013 at 09:04:00PM +1000, David Gibson wrote: > > On Wed, May 29, 2013 at 01:17:13PM +0300, Michael S. Tsirkin wrote: > > > On Wed, May 29, 2013 at 08:06:42PM +1000, David Gibson wrote: > > > > On Wed, May 29, 2013 at 12:55:53PM +0300, Michael S. Tsirkin wrote: > > > > > On Wed, May 29, 2013 at 07:43:41PM +1000, David Gibson wrote: > > > > > > On Thu, May 23, 2013 at 10:16:27PM +1000, David Gibson wrote: > > > > > > > On Thu, May 23, 2013 at 02:22:30PM +0300, Michael S. Tsirkin = wrote: > > > > > > > > On Thu, May 09, 2013 at 10:31:10AM +1000, David Gibson wrot= e: > > > > > > > > > Currently pci_get_primary_bus() searches the list of root= buses for one > > > > > > > > > with domain 0. But since host buses are always registere= d with domain 0, > > > > > > > > > this just amounts to finding the only PCI host bus. > > > > > > > > >=20 > > > > > > > > > This simplifies the implementation by defining the primar= y PCI bus to > > > > > > > > > be the first one registered, using a global variable to t= rack it. > > > > > > > > >=20 > > > > > > > > > Signed-off-by: David Gibson > > > > > > > >=20 > > > > > > > > Or better: can we just fail if there is more than > > > > > > > > one root? > > > > > > >=20 > > > > > > > That might work, I'll look into doing that. > > > > > >=20 > > > > > > So, the difficulty with this is that then any machine with mult= iple > > > > > > PCI bridges could not use pci_nic_init(), since it calls > > > > > > pci_get_bus_devfn() which calls pci_find_primary_bus() which wo= uld > > > > > > always fail. And using pci_nic_init() is more or less mandator= y in > > > > > > the machine_init function to support old-style nic configuratio= n. > > > > > >=20 > > > > > > Suggestions? > > > > >=20 > > > > > You mean multiple PCI roots? > > > > > Well, there are no legacy machines with multiple roots to support= , are > > > > > there? So why do we need to support legacy flags for these new > > > > > configurations? > > > >=20 > > > > Because people expect them. > > >=20 > > > People can learn, somehow they will learn to add a new root, so they = can > > > learn to use -device too. > >=20 > > Hrm. I'd kind of like a second (third?) opinion on that. Anthony? > >=20 > > > So let's make it fail on multiple roots, and output a message along t= he > > > lines of "please use -device virtio-net-pci instead". > >=20 > > How to produce a meaningful error like that isn't totally obvious, > > since the test for multiple roots is down in find_primary_pci_bus() > > (or whatever), and once we get back up to pci_nic_init() we just know > > that pci_get_bus_devfn() failed for some reason. >=20 > What other possible reason for it to fail? Unparseable address (it can be user specified) or internal failure to initialize the device are the first two that spring to mind.. > > > > Plus on spapr we already support the > > > > legacy nic options; it would be very strange for them to suddenly > > > > break when we add a second host bridge. > > >=20 > > > Not sure who "we" is here. IMHO user should ask for a new > > > machine type with two roots explicitly. > >=20 > > You seem to be thinking of the number of host bridges as a fixed > > property of the platform, which it isn't on spapr. PCI host bridges > > are just another device. Large scale real hardware can easily have > > dozens of them. >=20 > Absolutely. I'm not thinking of it as fixed. > I'm thinking of the *default* number of pci host bridges > as fixed. If a user is smart enough to use -device to create > a host bridge, said user can learn about -device for creating > a nic. Hm, I guess. I'm still uncomfortable with breaking a documented option, even if its not the preferred method these days. > > In qemu we create one always as a convenience, but > > users can (and will have to, for vfio) create additional ones > > trivially with -device. >=20 > So they know about -device then. >=20 > > [Which raises another complication as a tangent. People (and libvirt) > > don't generally expect -nodefaults to remove the PCI bridge, but > > arguably it should on spapr, since a PAPR guest with no PCI is > > perfectly viable but there's currently no way to specify such a > > thing.] >=20 > I guess the problem is not what they expect generally, > but specifically that some users might rely on spapr with > -nodefaults having PCI? I'm pretty sure libvirt will rely on that, if nothing else. > I don't have any ideas besides introducing a new machine type > that is same as spapr but without the default PCI host bridge. --=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 --/ZYM6PqDyfNytx60 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGmyNEACgkQaILKxv3ab8YUQwCfUXeZhFklxvc3/KYV+NSCauz+ 6RIAn0se6lr+scQ6dYkU8fKtMW1nJsAA =3P4T -----END PGP SIGNATURE----- --/ZYM6PqDyfNytx60--