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

[Blue Swirl]

On Sat, Sep 22, 2012 at 2:16 PM, Alexander Graf <address@hidden> wrote:
>
>
> On 22.09.2012, at 15:31, Blue Swirl <address@hidden> 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
>
> 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
>