From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGgGW-0001QQ-Dg for qemu-devel@nongnu.org; Tue, 25 Sep 2012 21:18:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGgGV-0005Qq-8f for qemu-devel@nongnu.org; Tue, 25 Sep 2012 21:18:16 -0400 Date: Wed, 26 Sep 2012 11:18:57 +1000 From: David Gibson Message-ID: <20120926011857.GC31993@truffula.fritz.box> References: <1348196931-9660-1-git-send-email-david@gibson.dropbear.id.au> <20120924003102.GB9800@truffula.fritz.box> <20120926002743.GN9800@truffula.fritz.box> <8788F852-B6E6-4B78-96B1-572D82350F9F@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8788F852-B6E6-4B78-96B1-572D82350F9F@suse.de> Subject: Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org On Wed, Sep 26, 2012 at 03:03:10AM +0200, Alexander Graf wrote: > On 26.09.2012, at 02:27, David Gibson wrote: > > On Mon, Sep 24, 2012 at 12:38:59PM +0200, Alexander Graf wrote: > >> On 24.09.2012, at 02:31, David Gibson wrote: [snip] > >>> So, if you look at the patch there is actually a -device form within > >>> there, the machine option is a wrapper around it. Without the machine > >>> option, I don't see how to get the desired properties for the > >>> configuration that is: > >>> * NVRAM is always instantiated by default (even if it's > >>> non-persistent) > >>> * It's easy to set the drive for that always-present NVRAM > >> > >> I suppose the idea is that when creating a machine from a qtree > >> dump, we can still recreate it. Or maybe when using -nodefaults? Not > >> sure. But the way you do it right now is very close to how we want > >> to model USB too, so I do like it. It's consistent. > > > > I really don't follow what point you're making here. > > > > The problem with -device syntax for my purpose is that with *no* extra > > command line arguments we should always have some sort of NVRAM - it's > > mandated by the platform spec, and should always be there, just like > > the PCI bridge and VIO bridge. That means instantiating the device > > from the machine setup code. But then, using -device will create a > > second instance of the device, which is no good, because only one can > > actually be used. > > What I'm trying to say is that the machine file should create a > device. Always in the case of PAPR. But I suppose pseudo-code is > easier to read: > > spapr.c: > > create_device("spapr-nvram", drive=machine_opts["nvram"]); Ok. That's what I do now. > spapr-nvram: > > if (!drive || checksum_is_bad(drive)) > autogenerate_nvram_contents(); Actually, I'm planning for the initialization of the content to be done from the guest firmware. > Then we can later add in vl.c: > > case OPTION_nvram: > create_drive("nvram", option); > machine_opts["nvram"] = drive["nvram"]; Ok, that all works for me. Blue, does that seem reasonable to you? -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson