On Sat, Sep 22, 2012 at 2:16 PM, Alexander Graf <ag...@suse.de> wrote: > > > On 22.09.2012, at 15:31, Blue Swirl <blauwir...@gmail.com> wrote: > >> On Fri, Sep 21, 2012 at 3:08 AM, David Gibson >> <da...@gibson.dropbear.id.au> 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. > > Of course we could also just introduce a -nvram option that machine > dependingly does create the device and block backend. More complex setups > where a machine doesn't fit into -bios and -nvram options (are there any?) > can then go with more complex syntax. > > But I don't want to force people to have to use -device syntax for the > average qemu use cases. Ever. If we go that route we could just as well > librarify all of QEMU and always link it with libvirt and only ever expose an > xml file for machine config to users. I don't use -device often either. The good side of -device syntax is that it forces people to think about for example multiple devices and how the devices fit together etc. > > > Alex >
