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

[Alexander Graf]

On 26.09.2012, at 22:03, Anthony Liguori <address@hidden> wrote:

> Alexander Graf <address@hidden> writes:
> 
>> 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.
> 
> We can't ask people to rewrite half of QEMU just to merge a feature.

Who is asking anyone to rewrite half of QEMU?

> 
> In this case, what matters is:
> 
> 0) The device should always be modelled with QOM/qdev

Yes

> 
> 1) If the device is a fundamental part of the machine (i.e. you can't do
>   anything useful with out it), then it's configuration should be
>   specified as a machine parameter.

Yes

> 
> 2) If !(1), the device should be added with -device

Yes

> 
> 3) Devices deal with backends and only with backends.  We have a syntax
>   for specifying backends independently of backends.

Yes

and

4) For often occuring use cases, we might want to provide a simplified cmdline 
syntax

> 
> If you want a single option to configure a device, that's a problem to
> attempt to solve independent of this series.

I never disagreed with that statement. We were merely brainstorming.

> 
>> But I don't want to force people to have to use -device syntax for the
>> average qemu use cases.
> 
> Sorry, but that's where we're at today.  -device is part of our user
> interface.  It's a management tool only interface and we cannot
> replicate every option just because you don't like the syntax.

Sure. And it's good to have. But we should also provide easier syntax for 
people without mgmnt tools, for use cases that occur often.

From the first xen vs kvm days one main argument about kvm was the difficulty 
in running it. People took the (overly complex) libvirt execution command line 
to QEMU and showed it to people. It did indeed scare a few.

So all I'm saying above is that we should not restrict ourselves to -device 
syntax, if we see a case that happens for more people than usual. However, I'd 
always try to model it as a shortcut form. So

  -nvram <file>

would just in the cmdline parser be converted to

  -drive file=<file>,if=none,id=nvram -machine nvram=nvram

I hope that makes my point a bit clearer. In fact, I'm quite sure we're in 
heavy agreement, so I'm not quite sure what you're complaining about :)

Alex

> 
> Regards,
> 
> Anthony Liguori