From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGrS5-0007xm-Px for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:29:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGrS0-0007la-CV for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:29:05 -0400 Received: from [199.232.76.173] (port=44781 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGrS0-0007lR-1u for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:29:00 -0400 Received: from mx2.redhat.com ([66.187.237.31]:55793) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGrRz-0002R3-G4 for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:28:59 -0400 Message-ID: <4A38B6CF.6000503@redhat.com> Date: Wed, 17 Jun 2009 12:26:39 +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: <4A364FE0.40204@redhat.com> <4A3651EB.3070204@codemonkey.ws> <4A36555A.4090303@redhat.com> <4A3659A0.3050108@codemonkey.ws> <4A366348.1030202@redhat.com> <1245083229.3222.103.camel@blaa> <4A368F12.2090504@codemonkey.ws> <1245154451.11407.22.camel@blaa> <4A378FE5.5050303@redhat.com> <1245155992.30082.8.camel@blaa> <20090616184404.GJ11893@shareable.org> <1245227632.27028.29.camel@blaa> <4A38B147.1030207@redhat.com> <1245230283.27028.36.camel@blaa> In-Reply-To: <1245230283.27028.36.camel@blaa> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark McLoughlin Cc: Carsten Otte , Rusty Russell , kvm@vger.kernel.org, "Michael S. Tsirkin" , Glauber Costa , dlaor@redhat.com, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Paul Brook On 06/17/2009 12:18 PM, Mark McLoughlin wrote: > On Wed, 2009-06-17 at 12:03 +0300, Avi Kivity wrote: > >> On 06/17/2009 11:33 AM, Mark McLoughlin wrote: >> >>>> I particularly don't like the idea of arcane machine-dependent slot >>>> allocation knowledge living in libvirt, because it needs to be in Qemu >>>> anyway for non-libvirt users. No point in having two implementations >>>> of something tricky and likely to have machine quirks, if one will do. >>>> >>> Indeed. >>> >> I don't understand this. >> > > Take note of the "arcane machine-dependent slot allocation knowledge" > bit. > > If the algorithm in for management apps is as simple as "query qemu for > available slots and sequentially allocate slots", then that's perfectly > fine. > That's the thinking. > If management apps need to hard-code which slots are available on > different targets and different qemu versions, or restrictions on which > devices can use which slots, or knowledge that some devices can be > multi-function, or ... anything like that is just lame. > You can't abstract these things away. If you can't put a NIC in slot 4, and you have 7 slots, then you cannot have 7 NICs. Having qemu allocate the slot numbers does not absolve management from knowing this limitation and preventing the user from creating a machine with 7 slots. Likewise, management will have to know which devices are multi-function, since that affects their hotpluggability. Ditto if some slot if faster than others, if you want to make use of this information you have to let the upper layers know. It could be done using an elaborate machine description that qemu exposes to management coupled with a constraint solver that optimizes the machine layout according to user specifications and hardware limitations. Or we could take the view that real life is not perfect (especially where computers are involved), add some machine specific knowledge, and spend the rest of the summer at the beach. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.