From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGBy9-0005wt-M4 for qemu-devel@nongnu.org; Mon, 15 Jun 2009 09:11:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGBy5-0005s6-2m for qemu-devel@nongnu.org; Mon, 15 Jun 2009 09:11:25 -0400 Received: from [199.232.76.173] (port=33460 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGBy4-0005ro-Sj for qemu-devel@nongnu.org; Mon, 15 Jun 2009 09:11:20 -0400 Received: from mx2.redhat.com ([66.187.237.31]:52735) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGBy4-0000s8-CC for qemu-devel@nongnu.org; Mon, 15 Jun 2009 09:11:20 -0400 Message-ID: <4A3647FB.9010808@redhat.com> Date: Mon, 15 Jun 2009 16:09:15 +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: <1244821292.30522.56.camel@blaa> <4A327E4A.7010300@codemonkey.ws> <1244825303.26769.19.camel@blaa> <20090614095016.GA7560@redhat.com> <1245056916.6891.31.camel@blaa> <4A3613EC.6030608@redhat.com> <20090615103249.GB6351@redhat.com> <4A363012.8050409@redhat.com> <20090615114858.GG6351@redhat.com> <4A3636FA.1040609@redhat.com> <20090615124101.GH6351@redhat.com> <4A364381.401@redhat.com> <4A364401.6010500@codemonkey.ws> In-Reply-To: <4A364401.6010500@codemonkey.ws> 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: Anthony Liguori Cc: Carsten Otte , Rusty Russell , kvm@vger.kernel.org, Mark McLoughlin , Glauber Costa , "Michael S. Tsirkin" , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Paul Brook On 06/15/2009 03:52 PM, Anthony Liguori wrote: > Avi Kivity wrote: >> On 06/15/2009 03:41 PM, Michael S. Tsirkin wrote: >>> We should just tell the user which slots are open. >>> This might be tricky if the config is passed in with the command line >>> flags. >> >> qemu -show-available-pci-slots > > Why does the user care? > > Let QEMU allocate the PCI slot, then query it to see what slot it > assigned and remember that. It's a roundabout way of doing things. As an example, if you try to fit too many devices into the machine, you have to try to add all devices and watch for a qemu error. If you know in advance how many slots you have, you never enter into that situation (and you need to show the limit to the user anyway). > > It's not a good idea to have management applications attempt to do PCI > slot allocation. For instance, one day we may decide to make virtio > devices multi-function. Non-virtio, as well. But we can't make that the default, so the user will have to specify this anyway. Given that you can't hotunplug individual functions, the user will have to specify exactly how functions are aggregated into devices. My recommendation would be for a GUI to allow the user to select a 'quad port virtio NIC' or 'dual port virtio scsi controller' rather than trying to do anything automatic. -- error compiling committee.c: too many arguments to function