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

[David Gibson]

On Sat, Sep 22, 2012 at 01:31:08PM +0000, Blue Swirl wrote:
> On Fri, Sep 21, 2012 at 3:08 AM, David Gibson
> <address@hidden> 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

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.

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