On 24.09.2012, at 02:31, David Gibson wrote: > On Sat, Sep 22, 2012 at 01:31:08PM +0000, Blue Swirl 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 > > 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. > Note that in our case the guest interface to the NVRAM precludes > having more than one instance of the device (the paravirtualized calls > to access it take no address or instance id). You can create multiple > with -device, but there will be no way to access them. Yes. But one of the future ideas in QEMU land is that you could recreate a machine from a dump of the current documentation, and thus it would require for a -device style instantiation. The default case for the command line shouldn't need that for obvious reasons :). Alex
