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