From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGxpM-0004BG-Dt for qemu-devel@nongnu.org; Wed, 26 Sep 2012 16:03:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGxpI-0006us-T2 for qemu-devel@nongnu.org; Wed, 26 Sep 2012 16:03:24 -0400 Received: from mail-oa0-f45.google.com ([209.85.219.45]:36014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGxpI-0006ud-Nn for qemu-devel@nongnu.org; Wed, 26 Sep 2012 16:03:20 -0400 Received: by oagi18 with SMTP id i18so963987oag.4 for ; Wed, 26 Sep 2012 13:03:19 -0700 (PDT) From: Anthony Liguori In-Reply-To: <219EFEC6-657A-48CA-886E-892636C7DCEA@suse.de> References: <1348196931-9660-1-git-send-email-david@gibson.dropbear.id.au> <219EFEC6-657A-48CA-886E-892636C7DCEA@suse.de> Date: Wed, 26 Sep 2012 15:03:15 -0500 Message-ID: <87zk4cv9fg.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 , Blue Swirl Cc: "qemu-ppc@nongnu.org" , "qemu-devel@nongnu.org" , David Gibson Alexander Graf writes: > 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. We can't ask people to rewrite half of QEMU just to merge a feature. In this case, what matters is: 0) The device should always be modelled with QOM/qdev 1) If the device is a fundamental part of the machine (i.e. you can't do anything useful with out it), then it's configuration should be specified as a machine parameter. 2) If !(1), the device should be added with -device 3) Devices deal with backends and only with backends. We have a syntax for specifying backends independently of backends. If you want a single option to configure a device, that's a problem to attempt to solve independent of this series. > But I don't want to force people to have to use -device syntax for the > average qemu use cases. Sorry, but that's where we're at today. -device is part of our user interface. It's a management tool only interface and we cannot replicate every option just because you don't like the syntax. Regards, Anthony Liguori