From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MF2OQ-0002jV-Nz for qemu-devel@nongnu.org; Fri, 12 Jun 2009 04:45:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MF2OL-0002ia-RP for qemu-devel@nongnu.org; Fri, 12 Jun 2009 04:45:46 -0400 Received: from [199.232.76.173] (port=49737 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MF2OL-0002iX-MT for qemu-devel@nongnu.org; Fri, 12 Jun 2009 04:45:41 -0400 Received: from mx2.redhat.com ([66.187.237.31]:60117) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MF2OL-0003dk-4n for qemu-devel@nongnu.org; Fri, 12 Jun 2009 04:45:41 -0400 Subject: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities] From: Mark McLoughlin In-Reply-To: <20090610192702.GH7416@shareable.org> References: <20090610145540.GI19375@poweredge.glommer> <20090610150129.GC28601@redhat.com> <200906101624.30659.paul@codesourcery.com> <20090610174301.GC7416@shareable.org> <20090610182227.GN28601@redhat.com> <20090610192702.GH7416@shareable.org> Content-Type: text/plain Date: Fri, 12 Jun 2009 09:43:29 +0100 Message-Id: <1244796209.16425.20.camel@blaa> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: Mark McLoughlin List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Carsten Otte , kvm@vger.kernel.org, "Michael S. Tsirkin" , Glauber Costa , Rusty Russell , qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org, Blue Swirl , Christian Borntraeger , Paul Brook , Avi Kivity On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote: > Michael S. Tsirkin wrote: > > > I think the right long term answer to all this is a way to get QEMU to > > > dump it's current machine configuration in glorious detail as a file > > > which can be reloaded as a machine configuration. > > > > And then we'll have the same set of problems there. > > We will, and the solution will be the same: options to create devices > as they were in older versions of QEMU. It only needs to cover device > features which matter to guests, not every bug fix. > > However with a machine configuration which is generated by QEMU, > there's less worry about proliferation of obscure options, compared > with the command line. You don't necessarily have to document every > backward-compatibility option in any detail, you just have to make > sure it's written and read properly, which is much the same thing as > the snapshot code does. This is a sensible plan, but I don't think we should mix these compat options in with the VM manager supplied configuration. There are two problems with that approach. = Problem 1 - VM manager needs to parse qemu config = Your proposal implies: - VM manager supplies a basic configuration to qemu - It then immediately asks qemu for a dump of the machine configuration in all its glorious detail and retains that config - If the VM manager wishes to add a new device it needs to parse the qemu config and add it, rather than just generate an entirely new config = Problem 2 - We can't predict the future = If a VM manager supplies a configuration which is missing any given option, qemu cannot tell the difference between: - This is a basic config, the VM manager wants whatever the default of the current qemu version - This is a complete config dumped using an old version of qemu, the VM manager wants the old default = Solution - Separate configuration from compat hints = As I suggested before: - Allow the VM manager to dump compat hints; this would be an opaque file format, more like the savevm format than a config file - Use defaults where compat hints are not available; e.g. if the VM manager specifies a device config, but no compat hints are supplied for it, then just use default values - Make the config override compat hints; e.g. if there are compat hints specified for a device not included in the machine config, just ignore those hints Cheers, Mark.