[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 6/8] pci: Simpler implementation of primary PCI
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH 6/8] pci: Simpler implementation of primary PCI bus |
Date: |
Thu, 6 Jun 2013 11:18:58 +0300 |
On Thu, Jun 06, 2013 at 05:39:11PM +1000, David Gibson wrote:
> 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
> > > > > > > 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 wrote:
> [snip]
> > > > > > So let's make it fail on multiple roots, and output a message along
> > > > > > the
> > > > > > lines of "please use -device virtio-net-pci instead".
> > > > >
> > > > > 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.
> > > >
> > > > 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..
> >
> > 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 suddenly
> > > > > > > break when we add a second host bridge.
> > > > > >
> > > > > > Not sure who "we" is here. IMHO user should ask for a new
> > > > > > machine type with two roots explicitly.
> > > > >
> > > > > 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.
> > > >
> > > > 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.
> >
> > Let's add
>
> Uh.. was there supposed to be the rest of a sentence there?
I meant let's add documentation that says -net nic is deprecated,
and not supported with multiple root devices, and to use
-device instead.
> --
> 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