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

[Alexander Graf]

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.


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