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

[Blue Swirl]

On Wed, Sep 26, 2012 at 8:51 PM, Alexander Graf <address@hidden> wrote:
>
>
> 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

The problem with this is that it hardcodes the nvram device to one and
only 'nvram'. What about CMOS and flash for x86, which one -nvram
would control?

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