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

[Blue Swirl]

On Sat, Sep 29, 2012 at 12:54 PM, Alexander Graf <address@hidden> wrote:
>
>
> On 29.09.2012, at 13:46, Blue Swirl <address@hidden> wrote:
>
>> 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?
>
> Then we invent a new option -cmos? These are just ideas. The bit about the 
> machine option is the important one :). Direct cmdline options really should 
> only be shortcuts.

Again, -flash, -cmos, -nvram? And then the same for the machine,
-machine nvram=foo,cmos=bar,flash=zerg?

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