From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbUvq-00080g-JJ for qemu-devel@nongnu.org; Thu, 22 Nov 2012 06:27:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbUvj-0002W9-R5 for qemu-devel@nongnu.org; Thu, 22 Nov 2012 06:26:58 -0500 References: <93E0DBC0-8611-4AF5-8035-B4AD409DD0D3@suse.de> <20121120122608.GA1756@redhat.com> <20121121005705.GM18362@truffula.fritz.box> <20121121113448.GA31911@redhat.com> <20121121123600.GV18362@truffula.fritz.box> <20121121131339.GA5730@redhat.com> <20121121132157.GW18362@truffula.fritz.box> <50ACD6AC.6030001@suse.de> <20121121152737.GC5730@redhat.com> <20121122022718.GY18362@truffula.fritz.box> <20121122072303.GA23260@redhat.com> In-Reply-To: <20121122072303.GA23260@redhat.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3190D38B-7409-455C-89C7-CD1F141EF19A@suse.de> From: Alexander Graf Date: Thu, 22 Nov 2012 12:27:49 +0100 Subject: Re: [Qemu-devel] [Qemu-ppc] [PATCH 12/12] pseries: Generate unique LIOBNs for PCI host bridges List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: "qemu-ppc@nongnu.org List" , qemu-devel qemu-devel , David Gibson On 22.11.2012, at 08:23, "Michael S. Tsirkin" wrote: > On Thu, Nov 22, 2012 at 01:27:18PM +1100, David Gibson wrote: >> On Wed, Nov 21, 2012 at 05:27:37PM +0200, Michael S. Tsirkin wrote: >>> On Wed, Nov 21, 2012 at 02:27:08PM +0100, Alexander Graf wrote: >>>> On 11/21/2012 02:21 PM, David Gibson wrote: >>>>> On Wed, Nov 21, 2012 at 03:13:39PM +0200, Michael S. Tsirkin wrote: >>>>>> On Wed, Nov 21, 2012 at 11:36:00PM +1100, David Gibson wrote: >>>>>>> On Wed, Nov 21, 2012 at 01:34:48PM +0200, Michael S. Tsirkin wrote: >>>>>>>> On Wed, Nov 21, 2012 at 11:57:05AM +1100, David Gibson wrote: >>>>>>>>> On Tue, Nov 20, 2012 at 02:26:09PM +0200, Michael S. Tsirkin wrote= : >>>>>>>>>> On Tue, Nov 20, 2012 at 10:27:11AM +0100, Alexander Graf wrote: >>>>>>>>>>> On 19.11.2012, at 23:51, David Gibson wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> On Mon, Nov 19, 2012 at 05:34:12PM +0100, Alexander Graf wrote:= >>>>>>>>>>>>> On 13.11.2012, at 03:47, David Gibson wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> From: Alexey Kardashevskiy >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> In future (with VFIO) we will have multiple PCI host bridges o= n >>>>>>>>>>>>>> pseries. Each one needs a unique LIOBN (IOMMU id). At the m= oment we >>>>>>>>>>>>>> derive these from the pci domain number, but the whole notion= of >>>>>>>>>>>>>> domain numbers on the qemu side is bogus and in any case they= 're not >>>>>>>>>>>>>> actually uniquely allocated at this point. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> This patch, therefore uses a simple sequence counter to gener= ate >>>>>>>>>>>>>> unique LIOBNs for PCI host bridges. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Signed-off-by: Alexey Kardashevskiy >>>>>>>>>>>>>> Signed-off-by: David Gibson >>>>>>>>>>>>> I don't really like the idea of having a global variable just >>>>>>>>>>>>> because our domain ID generation seems to not work as >>>>>>>>>>>>> expected. Michael, any comments here? >>>>>>>>>>>> Well, the patch I sent which changed domain id generation was >>>>>>>>>>>> ignored. In any case, as I said, the whole concept of domain n= umbers >>>>>>>>>>> Michael? >>>>>>>>>> This is user visible, right? >>>>>>>>>> So IMHO we should have the user specify LIOBN through a property,= >>>>>>>>>> rather than assign what's essentially a random value. >>>>>>>>> Well, I can implement an override through a property, which could b= e >>>>>>>>> useful in some circumstances. But we still need to have qemu gene= rate >>>>>>>>> unique defaults, rather than forcing it to be specified in every c= ase. >>>>>>>> I don't see why. >>>>>>>> And if you want automatic defaults then they need to be generated i= n a >>>>>>>> way that does not depend on implementation detail such as order of >>>>>>>> device initialization. >>>>>>> Because requiring explicit unique liobns to be supplied whenever the= re >>>>>>> is more than one PHB is horrible for usability. >>>>>> We should make simple things simple and complex things possible. >>>>>> More than one PHB seems like an advanced feature >>>>> Not for pseries. On real hardware of this type, dozens of PHBs is >>>>> routine. Plus, vfio passthrough is coming, we need at minimum one PHB= >>>>> for emulated devices and one for passthrough devices. >>>>=20 >>>> Yeah, I second Davids opinion here. We need to make this easy for users= . >>>=20 >>> I think users don't normally create PHBs. They request a disk, a network= >>> device, a pass-through device ... In this case if this requires >>> more PHBs create them internally but I imagine this doesn't >>> require any allocation scheme - simply set some address >>> for virtual devices, some other one for assigned devices ... no? >>=20 >> No. One PHB for passthrough and one for emulated is the minimum. >> Since we don't emulated p2p bridges, >=20 > Actually qemu does emulate p2p bridges. >=20 >> each PHB can only support a small >> number of PCI devices, so if enough PCI devices are requested, we will >> still need to create - and assign numbers to - additional PHBs. >=20 > Each PHB can support up to 32 slots right? This seems ample for > a typical use. If you want many tens of devices you need to > supply addresses manually, this looks reasonable to me. >=20 > Allocating PHBs on the fly seems unencessarily tricky. IIRC it's required for fault isolation. Alex >=20 >>> If user wants to play with low level detail such as PHBs I don't see why= >>> it's not reasonable to require full specification. >>>=20 >>>> How do we assign PCI slot IDs today when all you do is a -device? >>>> This should probably follow the same scheme. >>>>=20 >>>>=20 >>>> Alex >>>=20 >>> What we do is find a first free slow. But it's exactly why I worry: >>> changing pci addresses between qemu releases has been a source of pain >>> and compatibility hassles in the past. >>> The problem would be more manageable if you simply reserve some fixed >>> addresses for internal use, like we reserve slots for VGA and IDE, >>> though even that becomes a problem as we switch to q35. >>>=20 >>=20 >> --=20 >> David Gibson | I'll have my music baroque, and my code >> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _ot= her_ >> | _way_ _around_! >> http://www.ozlabs.org/~dgibson