From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tbtmz-0001MM-Qw for qemu-devel@nongnu.org; Fri, 23 Nov 2012 08:59:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tbtmv-0007Jw-S6 for qemu-devel@nongnu.org; Fri, 23 Nov 2012 08:59:29 -0500 Date: Fri, 23 Nov 2012 16:01:58 +0200 From: "Michael S. Tsirkin" Message-ID: <20121123140158.GB9153@redhat.com> References: <20121121132157.GW18362@truffula.fritz.box> <50ACD6AC.6030001@suse.de> <20121121152737.GC5730@redhat.com> <20121122022718.GY18362@truffula.fritz.box> <20121122072303.GA23260@redhat.com> <20121123041307.GD5588@truffula.fritz.box> <20121123105323.GB7051@redhat.com> <20121123125951.GC4071@truffula.fritz.box> <20121123134414.GA9153@redhat.com> <003DB287-169A-4A79-BE7D-5507DB1BEC92@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003DB287-169A-4A79-BE7D-5507DB1BEC92@suse.de> 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: Alexander Graf Cc: "qemu-ppc@nongnu.org List" , qemu-devel qemu-devel , David Gibson On Fri, Nov 23, 2012 at 02:44:15PM +0100, Alexander Graf wrote: > > On 23.11.2012, at 14:44, Michael S. Tsirkin wrote: > > > On Fri, Nov 23, 2012 at 11:59:51PM +1100, David Gibson wrote: > >>> Look, even if solution using a required property is less elegant for CLI > >>> use, it will work, won't it? > >>> So how about we merge it so that things work, and then we can discuss a > >>> patch on top that auto-generates this property? > >> > >> Well, there you have a point. And actually I've realised there are > >> other things we need to assign uniquely for each PHB and don't yet (IO > >> window addresses). So I need to look at a wider rework of this, which > >> I'll start on next week. > > > > Fine. Basically my point is it's typically a mistake to > > make some userspace visible parameter depend on order > > of initialization of devices in qemu. I don't insist > > on making users fully specify such parameters but it > > is one way to do this. > > I think it's reasonable to require to be able to specify it. If you > don't, it's fine to base on device order IMHO. Let me clarify why it's not fine. My understanding is these addresses do not change across reboots on real hardware. On the other hand order of initialization can change because of internal changes in qemu; thus shut down and start guest under another qemu version changes addresses. So it's a bug. No? > But you have to have the ability to specify it by hand if your > management tool of choice actually wants reproducible results. > > > Alex How do you know whether your guest relies on reproducible results? You typically don't. Imagine a guest which does rely on this. Then: What I propose: user runs qemu with many PHBs but with no iobns, gets error 'initialization failed. please add iobn=XXXX where XXXX is a unique number 1 to 64K.' What you propose: user runs qemu with many PHBs but with no iobns, guest fails to boot or behaves incorrectly. I think as a user I prefer the first type of failure. No? -- MST