qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] Re: optional feature
Date: Wed, 16 Sep 2009 17:12:45 +0300	[thread overview]
Message-ID: <20090916141245.GC5287@redhat.com> (raw)
In-Reply-To: <4AB0F17B.7000107@codemonkey.ws>

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.

  reply	other threads:[~2009-09-16 14:14 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-16 10:46 [Qemu-devel] optional feature (was Re: The State of the SaveVM format) Michael S. Tsirkin
2009-09-16 11:04 ` [Qemu-devel] Re: optional feature Juan Quintela
2009-09-16 11:18   ` Gleb Natapov
2009-09-16 11:48     ` Juan Quintela
2009-09-16 11:52       ` Michael S. Tsirkin
2009-09-16 12:14         ` Juan Quintela
2009-09-16 12:18           ` Michael S. Tsirkin
2009-09-16 12:26             ` Juan Quintela
2009-09-16 12:37               ` Michael S. Tsirkin
2009-09-16 13:01                 ` Juan Quintela
2009-09-16 13:03                   ` Michael S. Tsirkin
2009-09-16 13:34                     ` Juan Quintela
2009-09-16 14:02                       ` Michael S. Tsirkin
2009-09-16 11:57       ` Gleb Natapov
2009-09-16 12:23         ` Juan Quintela
2009-09-16 12:35           ` Gleb Natapov
2009-09-16 12:40             ` Michael S. Tsirkin
2009-09-16 13:22             ` Juan Quintela
2009-09-16 14:08               ` Anthony Liguori
2009-09-16 14:12                 ` Michael S. Tsirkin [this message]
2009-09-16 14:21                   ` Anthony Liguori
2009-09-16 14:34                     ` Michael S. Tsirkin
2009-09-16 14:53                       ` Juan Quintela
2009-09-16 15:11                         ` Michael S. Tsirkin
2009-09-16 15:25                           ` Juan Quintela
2009-09-16 15:45                       ` Anthony Liguori
2009-09-16 15:58                         ` Anthony Liguori
2009-09-16 13:51         ` Anthony Liguori
2009-09-16 11:41   ` Michael S. Tsirkin
2009-09-16 12:13     ` Juan Quintela
2009-09-16 12:29       ` Michael S. Tsirkin
2009-09-16 13:31         ` Juan Quintela
2009-09-16 14:07           ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090916141245.GC5287@redhat.com \
    --to=mst@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=gleb@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).