From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MnvHM-0006NM-CK for qemu-devel@nongnu.org; Wed, 16 Sep 2009 10:14:40 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MnvHH-0006MZ-Da for qemu-devel@nongnu.org; Wed, 16 Sep 2009 10:14:39 -0400 Received: from [199.232.76.173] (port=53192 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MnvHH-0006MP-8t for qemu-devel@nongnu.org; Wed, 16 Sep 2009 10:14:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:29590) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MnvHG-0003vb-Sy for qemu-devel@nongnu.org; Wed, 16 Sep 2009 10:14:35 -0400 Date: Wed, 16 Sep 2009 17:12:45 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: optional feature Message-ID: <20090916141245.GC5287@redhat.com> References: <20090916104620.GA4456@redhat.com> <20090916111845.GJ23157@redhat.com> <20090916115726.GL23157@redhat.com> <20090916123535.GM23157@redhat.com> <4AB0F17B.7000107@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AB0F17B.7000107@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Gleb Natapov , Juan Quintela On Wed, Sep 16, 2009 at 09:08:59AM -0500, Anthony Liguori wrote: > Juan Quintela wrote: >>>> up rtc version +1 >>>> add the two fields that we need (together with rtc-td-hack value) >>>> >>> And why this is better? You can't migrate old VM to new qemu even if you >>> don't use rtc-td-hack on new one. >>> >> >> I think the difference between us is: >> - is rtc-td-hack a hack that should only be used for some users >> - it is a valid rtc feature that should be available to everybody >> - it is independent, or it needs an rtc to have any value. >> > > We need a single table that contains the full state for the device. > > Many devices will have knobs. There are two likely types of knobs: > > 1) something that indicates how an array of state is going to be > 2) a boolean that indicates whether a portion of state is valid > > rtc-td falls into the second category. It makes sense to me that the > table state would contain a boolean to indicate whether a given set of > state was valid. You may need a grouping mechanism for this. It > probably makes sense to do this as separate tables. For instance, > > .fields = (VMStateField []) { > VMSTATE_BOOL(td_hack, RTCState, (VMStateField[]){ > VMSTATE_INT32(irq_coalesced, RTCState), > VMSTATE_INT32(period, RTCState), > VMSTATE_END_OF_LIST()}), > } > > If we can't maintain backwards compatibility using this approach (we > definitely can't for rtc-td) then we'll just have to live with that. We have to? Why do we? And not only won't we have backwards compatibility now, we will also break it and have to break it each time we add a knob. If instead we would only save/load the part of state if the knob is set, we won't have a problem. > I also think arrays should be expressed like this FWIW. Today we have > explicit typed arrays. I would rather see: > > .fields = (VMStateField []) { > VMSTATE_ARRAY(nirq, PCIBus, (VMStateField[]) { > VMSTATE_INT32(irq_count[0], PCIBus), > VMSTATE_END_OF_LIST()}), > } Same problem here.