On 29.09.2012, at 16:11, Blue Swirl <blauwir...@gmail.com> wrote:
> 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? 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