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

[Alexander Graf]

On 29.09.2012, at 16:11, Blue Swirl <address@hidden> wrote:

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

Yup ;). Though I would probably call flash 'bios', since that is essentially 
what -bios does today.

Alex

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