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. 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. Alex
