From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MnvC6-00039M-Rs
	for qemu-devel@nongnu.org; Wed, 16 Sep 2009 10:09:14 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MnvC2-000366-1E
	for qemu-devel@nongnu.org; Wed, 16 Sep 2009 10:09:14 -0400
Received: from [199.232.76.173] (port=42777 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MnvC1-00035n-Rv
	for qemu-devel@nongnu.org; Wed, 16 Sep 2009 10:09:09 -0400
Received: from mail-yx0-f201.google.com ([209.85.210.201]:52899)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1MnvC1-0002wc-Hu
	for qemu-devel@nongnu.org; Wed, 16 Sep 2009 10:09:09 -0400
Received: by yxe39 with SMTP id 39so6284539yxe.18
	for <qemu-devel@nongnu.org>; Wed, 16 Sep 2009 07:09:08 -0700 (PDT)
Message-ID: <4AB0F17B.7000107@codemonkey.ws>
Date: Wed, 16 Sep 2009 09:08:59 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: optional feature
References: <20090916104620.GA4456@redhat.com>
	<m34or3up58.fsf@neno.mitica>	<20090916111845.GJ23157@redhat.com>
	<m3ocpbt8j0.fsf@neno.mitica>	<20090916115726.GL23157@redhat.com>
	<m3bplbt6wq.fsf@neno.mitica>	<20090916123535.GM23157@redhat.com>
	<m37hvznhwh.fsf@neno.mitica>
In-Reply-To: <m37hvznhwh.fsf@neno.mitica>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>

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.

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()}),
}