Re: [Qemu-devel] [Qemu-ppc] RFC: NVRAM for pseries machine

[David Gibson <david@gibson.dropbear.id.au>]

On Sat, Sep 22, 2012 at 02:26:43PM +0000, Blue Swirl wrote:
> On Sat, Sep 22, 2012 at 2:16 PM, Alexander Graf <agraf@suse.de> wrote:
> >
> >
> > On 22.09.2012, at 15:31, Blue Swirl <blauwirbel@gmail.com> wrote:
> >
> >> On Fri, Sep 21, 2012 at 3:08 AM, David Gibson
> >> <david@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.

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