On Fri, Oct 29, 2010 at 11:54:27AM +0200, Markus Armbruster wrote: > [Note cc: Michael & Gerd] > > Isaku Yamahata <yamah...@valinux.co.jp> writes: > > > On Fri, Oct 29, 2010 at 10:02:47AM +0200, Markus Armbruster wrote: > >> Isaku Yamahata <yamah...@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)