From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MG8lo-0003Ng-GP for qemu-devel@nongnu.org; Mon, 15 Jun 2009 05:46:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MG8lj-0003FY-Hq for qemu-devel@nongnu.org; Mon, 15 Jun 2009 05:46:28 -0400 Received: from [199.232.76.173] (port=43741 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MG8lj-0003FK-9X for qemu-devel@nongnu.org; Mon, 15 Jun 2009 05:46:23 -0400 Received: from mx2.redhat.com ([66.187.237.31]:36272) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MG8li-0003Ai-N8 for qemu-devel@nongnu.org; Mon, 15 Jun 2009 05:46:23 -0400 Message-ID: <4A3617D4.5090405@redhat.com> Date: Mon, 15 Jun 2009 12:43:48 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities] References: <20090610150129.GC28601@redhat.com> <200906101624.30659.paul@codesourcery.com> <20090610174301.GC7416@shareable.org> <20090610182227.GN28601@redhat.com> <20090610192702.GH7416@shareable.org> <1244796209.16425.20.camel@blaa> <4A326B5C.5010501@codemonkey.ws> <1244821292.30522.56.camel@blaa> <4A327E4A.7010300@codemonkey.ws> <1244825303.26769.19.camel@blaa> <20090614095016.GA7560@redhat.com> In-Reply-To: <20090614095016.GA7560@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Mark McLoughlin , kvm@vger.kernel.org, Carsten Otte , Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Paul Brook On 06/14/2009 12:50 PM, Michael S. Tsirkin wrote: > On Fri, Jun 12, 2009 at 05:48:23PM +0100, Mark McLoughlin wrote: > >> However, in order to retain compat for that SCSI device (e.g. ensuring >> the PCI address doesn't change as other devices are added an removed), >> we're back to the same problem ... either: >> >> 1) Use '-drive file=foo.img,if=scsi,pci_addr=foo'; in order to figure >> out what address to use, libvirt would need to query qemu for what >> address was originally allocated to device or it would do all the >> PCI address allocation itself ... >> > > This last option makes sense to me: in a real world the user has > control over where he places the device on the bus, so why > not with qemu? > Yes, the user build the machine using the command line and monitor (or, in 2017, the machine configuration file), then turns on the power. Command line options are the parts lying around when we start. btw, -drive needs to be separated: -controller type=lsi1234,pci_addr=foobar,name=blah -drive file=foo.img,controller=blah,index=0 -drive file=bar.img,controller=blah,index=1 Drives to not have pci addresses. -- error compiling committee.c: too many arguments to function