From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkVME-0006sC-QC for qemu-devel@nongnu.org; Thu, 06 Jun 2013 04:15:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UkVM6-00064R-9C for qemu-devel@nongnu.org; Thu, 06 Jun 2013 04:15:42 -0400 Received: from ozlabs.org ([2402:b800:7003:1:1::1]:41417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkVM5-00063p-Lq for qemu-devel@nongnu.org; Thu, 06 Jun 2013 04:15:34 -0400 Date: Thu, 6 Jun 2013 17:39:11 +1000 From: David Gibson Message-ID: <20130606073911.GA24421@voom.bne.redhat.com> References: <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> <20130530033441.GL5489@boomeroo.fritz.box> <20130530050227.GB6168@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline In-Reply-To: <20130530050227.GB6168@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 --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 30, 2013 at 08:02:27AM +0300, Michael S. Tsirkin wrote: > On Thu, May 30, 2013 at 01:34:41PM +1000, David Gibson wrote: > > 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 wr= ote: > > > > > > > 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 wrot= e: > > > > > > > > > On Thu, May 23, 2013 at 02:22:30PM +0300, Michael S. Tsir= kin wrote: > > > > > > > > > > On Thu, May 09, 2013 at 10:31:10AM +1000, David > Gibson wrote: [snip] > > > > > So let's make it fail on multiple roots, and output a message alo= ng the > > > > > 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 kn= ow > > > > that pci_get_bus_devfn() failed for some reason. > > >=20 > > > What other possible reason for it to fail? > >=20 > > Unparseable address (it can be user specified) or internal failure to > > initialize the device are the first two that spring to mind.. >=20 > Well, let's change the API in some way. How about we > pass root to pci_get_bus_devfn? Alrighty, that I can do. I was initially hesitant, since at least notionally the given PCI address string can include a domain, but we're already pretty much explicitly disabling that, and none of the built-in examples use it, so I think it's fine. > > > > > > Plus on spapr we already support the > > > > > > legacy nic options; it would be very strange for them to sudden= ly > > > > > > 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. > >=20 > > Hm, I guess. I'm still uncomfortable with breaking a documented > > option, even if its not the preferred method these days. >=20 > Let's add=20 Uh.. was there supposed to be the rest of a sentence there? --=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 --/04w6evG8XlLl3ft Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) iEYEARECAAYFAlGwPJ8ACgkQaILKxv3ab8YjWACgk1iEbL7MAhzwFtZSWECcHuyj TeoAnApAQ19afPqoTNO8ynPX32XHHwTK =z64P -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft--