From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MGF3p-00068C-4h
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 12:29:29 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MGF3k-000663-ND
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 12:29:28 -0400
Received: from [199.232.76.173] (port=52579 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MGF3k-00065z-H7
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 12:29:24 -0400
Received: from mx2.redhat.com ([66.187.237.31]:53674)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <markmc@redhat.com>) id 1MGF3k-0004Cu-3i
	for qemu-devel@nongnu.org; Mon, 15 Jun 2009 12:29:24 -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: <4A3664EE.30207@redhat.com>
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>
Content-Type: text/plain
Date: Mon, 15 Jun 2009 17:27:11 +0100
Message-Id: <1245083231.3222.104.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: dlaor@redhat.com
Cc: Carsten Otte <cotte@de.ibm.com>, kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>, Glauber Costa <glommer@redhat.com>, Rusty Russell <rusty@rustcorp.com.au>, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl <blauwirbel@gmail.com>, Christian Borntraeger <borntraeger@de.ibm.com>, Avi Kivity <avi@redhat.com>, Paul Brook <paul@codesourcery.com>

On Mon, 2009-06-15 at 18:12 +0300, 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.

Absolutely. And not just about what most helps end users of libvirt
based management apps, but also any app managing qemu.

> 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.

Providing end users with the *option* to choose PCI slots sounds like a
fine feature request for any management app.

Requiring all management apps to force end users to explicitly choose
PCI slots in order for slots to be stable is not so reasonable.

Cheers,
Mark.