Re: [Qemu-devel] Re: May I use -device in qemu-system command to attach to PCIe bus?

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Oct 29, 2010 at 11:54:27AM +0200, Markus Armbruster wrote:
> [Note cc: Michael & Gerd]
> 
> Isaku Yamahata <yamahata@valinux.co.jp> writes:
> 
> > On Fri, Oct 29, 2010 at 10:02:47AM +0200, Markus Armbruster wrote:
> >> Isaku Yamahata <yamahata@valinux.co.jp> writes:
> >> 
> >> > On Thu, Oct 28, 2010 at 03:37:27AM -0700, Wei Xu wrote:
> >> >> Isaku,
> >> >> 
> >> >> To make things clear, let me rephrase the problem. With q35/vPCIe, in VMM
> >> >> monitor, we can do hotplug like:
> >> >>  pci_add auto|<bus:dev> nic|storage
> >> >> to hotplug a device to PCIe/PCI bus.
> >> >> 
> >> >> But we have two problems  here:
> >> >> (1) command line for example, "-net nic,addr=<bus:dev>" always failed
> >> >> because it cannot find the bus.
> >> >> (2) If "pci_add auto" in monitor or no "addr=<bus:dev" in command line, the
> >> >> device will be attached to PCI bus, in stead of PCIe ports
> >> >> 
> >> >> I solved the first problem. The root cause is pcie_root_write_config (which
> >> >> init SECONDARY_BUS config) happened after pci_nic_init. The latter use
> >> >> pci_find_bus to find the parent bus but failed because config space for
> >> >> secondary bus still not initialized.
> >> >
> >> > Okay, now the issue is clear to me.
> >> > When I tried to clean up pci bridge code, I included the similar lines
> >> > in bridge initialization function.
> >> > But Michael complained about it, so I dropped the lines for merge.
> >> >
> >> > I think there are two ways to address it.
> >> > - initialize secondary/subordinate bus register by qemu
> >> >   i.e. something like the patch below.
> >> >
> >> > - use qdev device path
> >> >   i.e. qbus_find() instead of pci_find_bus().
> >> >   I don't know if the corresponding command line option already exists or not.
> >> >
> >> > My preference is the former, but discussion is necessary to get consensus.
> >> > My plan was to raise the issue when I address pv pci bus numbering issue.
> >> > I've expected that other developers wouldn't think the issue important
> >> > because multiple pci bus can't be used easily right now.
> >> 
> >> I'm afraid I'm missing context here.  Could you restate the problem?
> >
> > Wei, please correct/clarify me if I'm wrong.
> >
> > The issues is that pci address, (segment, bus, dev, fn), doesn't always
> > work as an argument to qemu command line or qemu monitor because
> > pci bus numbering is done by guest BIOS/OS.
> > In flat pci bus case, i.e. there is a single pci bus of bus=0,
> > fortunately it works.
> > But if there are multiple pci buses, (segment, bus, dev, fn)
> > doesn't work as expected until guest bios/os numbers pci buses.
> > For example if pci bus address with non-0 bus number is passed as
> > qemu command line option in order to add pci device, qemu fails to
> > find the pci bus.
> 
> Guest-assigned addresses need not be stable and predictable.  Using them
> for QEMU device configuration feels wrong to me.
> 
> Is there a way to name a PCI bus that is independent of guest software?

What was proposed was a hierarchical path from root to the device.
E.g. segment/device/device/device, specifying the device numbers
of each bus on the parent bus.
No one got around to implementing this.

> >> New devices and buses need to work with -device / device_add.  pci_add
> >> and -net nic are for backwards compatibility.  Folks used to them may
> >> appreciate you making them work for PCIe.  Longer term, they should
> >> either go away or become syntactic sugar.
> >
> > The issue is caused not by pcie, but by multiple pci buses.
> 
> Got it.
> 
> > I suppose that -device/device_add uses qdev path, not pci address,
> > so it would be okay.
> 
> Yes, except qdev paths are a bit of a mess right now.  Separate problem.
> 
> > pci_add or -net nic wouldn't work. (or only works with bus=0)