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? 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.