From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MGrKA-00057V-P0
	for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:20:55 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MGrK5-00051G-AH
	for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:20:53 -0400
Received: from [199.232.76.173] (port=43354 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MGrK5-000518-5E
	for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:20:49 -0400
Received: from mx20.gnu.org ([199.232.41.8]:24035)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <markmc@redhat.com>) id 1MGrK4-0007it-Of
	for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:20:48 -0400
Received: from mx2.redhat.com ([66.187.237.31])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <markmc@redhat.com>) id 1MGrK3-0001NR-WC
	for qemu-devel@nongnu.org; Wed, 17 Jun 2009 05:20:48 -0400
Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3
	03/13] qemu: add routines to manage PCI capabilities]
From: Mark McLoughlin <markmc@redhat.com>
In-Reply-To: <4A38B147.1030207@redhat.com>
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>
Content-Type: text/plain
Date: Wed, 17 Jun 2009 10:18:03 +0100
Message-Id: <1245230283.27028.36.camel@blaa>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Reply-To: Mark McLoughlin <markmc@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Carsten Otte <cotte@de.ibm.com>, Rusty Russell <rusty@rustcorp.com.au>, kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>, Glauber Costa <glommer@redhat.com>, dlaor@redhat.com, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl <blauwirbel@gmail.com>, Christian Borntraeger <borntraeger@de.ibm.com>, Paul Brook <paul@codesourcery.com>

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.

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.

Cheers,
Mark.