From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54383 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBli4-0005mM-3h for qemu-devel@nongnu.org; Fri, 29 Oct 2010 05:57:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBlfM-0004CQ-OZ for qemu-devel@nongnu.org; Fri, 29 Oct 2010 05:55:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5803) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBlfM-0004Bm-9G for qemu-devel@nongnu.org; Fri, 29 Oct 2010 05:54:32 -0400 From: Markus Armbruster Subject: Re: [Qemu-devel] Re: May I use -device in qemu-system command to attach to PCIe bus? References: <20101028051640.GK2243@valinux.co.jp> <20101028112548.GC5851@valinux.co.jp> <20101029084036.GB6696@valinux.co.jp> Date: Fri, 29 Oct 2010 11:54:27 +0200 In-Reply-To: <20101029084036.GB6696@valinux.co.jp> (Isaku Yamahata's message of "Fri, 29 Oct 2010 17:40:36 +0900") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Isaku Yamahata Cc: "Subbiah Kandasamy (skandasa)" , Gerd Hoffmann , qemu-devel@nongnu.org, Wei Xu , "Michael S. Tsirkin" [Note cc: Michael & Gerd] Isaku Yamahata writes: > On Fri, Oct 29, 2010 at 10:02:47AM +0200, Markus Armbruster wrote: >> Isaku Yamahata 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| nic|storage >> >> to hotplug a device to PCIe/PCI bus. >> >> >> >> But we have two problems here: >> >> (1) command line for example, "-net nic,addr=" always failed >> >> because it cannot find the bus. >> >> (2) If "pci_add auto" in monitor or no "addr=> >> 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? >> 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)