From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TFwsI-0008Ts-Qb for qemu-devel@nongnu.org; Sun, 23 Sep 2012 20:50:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TFwsH-0001FS-48 for qemu-devel@nongnu.org; Sun, 23 Sep 2012 20:50:14 -0400 Date: Mon, 24 Sep 2012 10:34:07 +1000 From: David Gibson Message-ID: <20120924003407.GC9800@truffula.fritz.box> References: <1348196931-9660-1-git-send-email-david@gibson.dropbear.id.au> <219EFEC6-657A-48CA-886E-892636C7DCEA@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: "qemu-ppc@nongnu.org" , Alexander Graf , "qemu-devel@nongnu.org" On Sat, Sep 22, 2012 at 02:26:43PM +0000, Blue Swirl wrote: > On Sat, Sep 22, 2012 at 2:16 PM, Alexander Graf wrote: > > > > > > On 22.09.2012, at 15:31, Blue Swirl wrote: > > > >> On Fri, Sep 21, 2012 at 3:08 AM, David Gibson > >> wrote: > >>> Below is a patch which implements the (PAPR mandated) NVRAM for the > >>> pseries machine. It raises a couple of generic questions. > >>> > >>> First, this adds a new "nvram" machine option which is used to give a > >>> block device id to back the NVRAM so it is persistent. Since some > >>> sort of NVRAM is quite common, it seems this might be useful on other > >>> machines one day, although obviously nothing else implements it yet. > >> > >> Yes, there have been discussions earlier since loading NVRAM contents > >> from a file would be useful for many architectures too. > >> > >>> > >>> Second, if a block device is not specified, it simply allocates a > >>> block of memory to make a non-persistent NVRAM. Obviously that isn't > >>> really "NV", but it's enough to make many guests happy most of the > >>> time, and doesn't require setting up an image file and drive. It does > >>> mean a different set of code paths in the driver though, and it will > >>> need special case handling for savevm (not implemented yet). Is this > >>> the right approach, or should I be creating a dummy block device for a > >>> one-run NVRAM of this kind? I couldn't see an obvious way to do that, > >>> but maybe I'm missing something. > >> > >> That was the problem earlier too, it looks like a generic way for all > >> NVRAM/flash devices should be obvious but so far nobody has been able > >> to propose something. > >> > >> What if there are two devices which could use this, for example CMOS > >> and flash on x86? > >> > >> This should be extending -device syntax rather than adding another > >> top level option. Something like > >> -drive foo,file=nvram.qcow2,format=qcow2,id=main_nvram -device > >> spapr-nvram,drive_id=main_nvram > > > > Could we create a simplified syntax for this in addition? Something like > > > > -device spapr-nvram,file=nvram.raw > > > > which would then automatically spawn a drive for the user. Saving the machine state would obviously save the transparently created drive. > > That would be nice too. Maybe NVRAM-like devices should just declare > that they support backing storage and this would then be attached > automatically if either file=blah or id=drive_id is specified. Well, that might be cool. But can we come to some sort of consensus or otherwise on whether this approach is a good start, rather than wandering off into how we can extend it just now? -- 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