From patchwork Thu Oct 28 10:37:27 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wei Xu X-Patchwork-Id: 69450 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 190AAB70D6 for ; Thu, 28 Oct 2010 21:40:55 +1100 (EST) Received: from localhost ([127.0.0.1]:39468 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBPue-0006fp-1F for incoming@patchwork.ozlabs.org; Thu, 28 Oct 2010 06:40:52 -0400 Received: from [140.186.70.92] (port=58946 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBPri-0005j0-6W for qemu-devel@nongnu.org; Thu, 28 Oct 2010 06:37:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBPrg-0000LB-Li for qemu-devel@nongnu.org; Thu, 28 Oct 2010 06:37:50 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]:26114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBPrg-0000K3-87 for qemu-devel@nongnu.org; Thu, 28 Oct 2010 06:37:48 -0400 Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFLuyEyrR7Hu/2dsb2JhbAChSHGidpwphUgEhFeFfIMO X-IronPort-AV: E=Sophos;i="4.58,250,1286150400"; d="scan'208";a="277115413" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 28 Oct 2010 10:37:37 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9SAbbDa019352; Thu, 28 Oct 2010 10:37:37 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Oct 2010 03:37:36 -0700 Received: from 10.21.119.54 ([10.21.119.54]) by xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Oct 2010 10:37:36 +0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 28 Oct 2010 03:37:27 -0700 From: Wei Xu To: Isaku Yamahata , Message-ID: Thread-Topic: May I use -device in qemu-system command to attach to PCIe bus? Thread-Index: Act2jB1Y79ETdda9JEKszpQz3bBPrg== In-Reply-To: <20101028051640.GK2243@valinux.co.jp> X-Priority: 2 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Oct 2010 10:37:36.0981 (UTC) FILETIME=[234B0850:01CB768C] X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. Cc: "Subbiah Kandasamy \(skandasa\)" Subject: [Qemu-devel] Re: May I use -device in qemu-system command to attach to PCIe bus? X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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= wrote: > Oh, now I'm seeing your point. Some codes of qemu assume that > the pci bus is flat. They need fixes. > > Right now I've found > - parse_pci_devfn in qdev-properties.c > This corresponds to (1) > - pci_get_bus_devfn() in pci.c > This corresponds to (2) > > thanks, > > On Wed, Oct 27, 2010 at 08:51:29PM -0700, Wei Xu wrote: >> Isaku, >> >> I found two issues: >> (1) command line option is not working: even with addr=, it complained >> bus cannot be found; >> (2) monitor: pci_add auto ... cannot work. >> >> Wei >> >> >> On 10/27/10 8:03 PM, "Isaku Yamahata" wrote: >> >>> On Wed, Oct 27, 2010 at 09:51:47AM -0700, Wei Xu wrote: >>>> Isaku, >>>> >>>> I have one question regarding EP and PCIe bus: now only way is to use >>>> "pci_add .." to hot-plug the device to a PCIe port. Looks like >>>> command line with -device parameter automatically use PCI bus? Is it >>>> possible to support it? Have to provide the in -device parameter? >>> >>> I'm not sure I got your question right. >>> We can populate the device under an express port with -device command line >>> option. At least it should be possible. >>> >>> For implementation detail, qemu doesn't distinguish pci express >>> from conventional pci so strictly. >>> The only difference is whether the bridge(pci host bridge or >>> pci-to-pci bridge) is just express port because I implemented express >>> ports as pci-to-pci bridge. >>> >>> Or do you want to add express port with command line option? >>> If so, not possible at the moment. >> diff --git a/hw/pci_bridge.c b/hw/pci_bridge.c index c048305..042c1f9 100644 --- a/hw/pci_bridge.c +++ b/hw/pci_bridge.c @@ -203,6 +203,7 @@ void pci_bridge_set_bus_number(PCIBridge *br, uint16_t domain; uint8_t primary_bus; uint8_t devfn; + uint8_t *conf; if (!pci_bus_number) { pci_bus_number = qemu_mallocz(sizeof(*pci_bus_number)); @@ -215,10 +216,15 @@ void pci_bridge_set_bus_number(PCIBridge *br, d = &br->dev; devfn = d->devfn; + conf = d->config; br->sec_bus = secondary; br->sub_bus = subordinate; + //TODO wexu2 workaround of "-net nic,addr=" + pci_set_byte(conf + PCI_SECONDARY_BUS, secondary); + pci_set_byte(conf + PCI_SUBORDINATE_BUS, subordinate); + bus = d->bus; primary_bus = 0; if ((d = pci_bridge_get_device(bus)) != NULL){