On Sat, Sep 29, 2012 at 12:54 PM, Alexander Graf <ag...@suse.de> wrote: > > > On 29.09.2012, at 13:46, Blue Swirl <blauwir...@gmail.com> wrote: > >> On Wed, Sep 26, 2012 at 8:51 PM, Alexander Graf <ag...@suse.de> wrote: >>> >>> >>> On 26.09.2012, at 22:03, Anthony Liguori <anth...@codemonkey.ws> wrote: >>> >>>> Alexander Graf <ag...@suse.de> writes: >>>> >>>>> On 22.09.2012, at 15:31, Blue Swirl <blauwir...@gmail.com> wrote: >>>>> >>>>>> On Fri, Sep 21, 2012 at 3:08 AM, David Gibson >>>>>> <da...@gibson.dropbear.id.au> 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
