From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGDx3-0001Y8-9m for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:18:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGDwx-0001W3-JO for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:18:23 -0400 Received: from [199.232.76.173] (port=34290 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGDwx-0001Vt-1I for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:18:19 -0400 Received: from mx2.redhat.com ([66.187.237.31]:49805) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGDww-0007un-KG for qemu-devel@nongnu.org; Mon, 15 Jun 2009 11:18:18 -0400 Message-ID: <4A3665A0.7000702@redhat.com> Date: Mon, 15 Jun 2009 18:15:44 +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: <4A364381.401@redhat.com> <4A364401.6010500@codemonkey.ws> <4A3647FB.9010808@redhat.com> <4A364B53.9080007@codemonkey.ws> <4A364FE0.40204@redhat.com> <4A3651EB.3070204@codemonkey.ws> <4A36555A.4090303@redhat.com> <4A3659A0.3050108@codemonkey.ws> <20090615143737.GB14405@redhat.com> <4A3662BA.6030304@codemonkey.ws> <20090615150804.GH7233@redhat.com> <4A3664EE.30207@redhat.com> In-Reply-To: <4A3664EE.30207@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: dlaor@redhat.com Cc: Carsten Otte , kvm@vger.kernel.org, "Michael S. Tsirkin" , Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Paul Brook , Mark McLoughlin On 06/15/2009 06:12 PM, Dor Laor wrote: >> It doesn't want to. As Mark said, libvirt just wants to be able to >> ensure >> a stable guest ABI, of which stable PCI addresses is one aspect. This >> does >> not imply libvirt wants to allocate the PCI addresses, just that it >> wants >> a way to keep them stable. All else being equal I'd rather libvirt >> wasn't >> in the PCI address allocation business. > > > It's not about what libvirt wants. It's about what will serve the end > user the most. > Apart for stable guest ABI, end users need to have the option to > control the slot for > their devices. Just like them have for physical machines. It's not > theoretical discussion, > limiting issues with shared irq is one real life example. > Another issue is enumeration. Guests will present their devices in the order they find them on the pci bus (of course enumeration is guest specific). So if I have 2 virtio controllers the only way I can distinguish between them is using their pci slots. -- error compiling committee.c: too many arguments to function