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