All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC 0/5] New VMState table based load/save infrastructure
Date: Wed, 19 Aug 2009 09:41:46 +0200	[thread overview]
Message-ID: <4A8BACBA.9020107@redhat.com> (raw)
In-Reply-To: <cover.1250601335.git.quintela@redhat.com>

> What do I want to discuss:
> a- do we want to be able to load state form old versions?
>     I am not sure that we are going to get this right for complex devices,
>     and I don't completely see how we can have any kind of testing here.
>     There was already a discussion about this on the list.

Yes, we want.  And I think the right approach to do that is to simply 
use the old, existing code and switch based on version_id.  To stick 
with the apic example:  When loadvm finds a v2 (or older) apic section, 
go call apic_load.  When loadvm finds a v3 (or newer) apic section, call 
the new generic load code with the apic vmstatefield list.

> b- Is this the right approach?  What more do we want/need?
>     For instance, implementing struct save support, and calling
>     other "sub-descriptions" is not difficult, we just have to decide
>     if we want it.

Yes, we want.  PCI devices call a generic function to save pci state. 
We want a common pci vmstatefield list too and have some way to refer to 
them from the device tables.

> c- In the current approach, we have loops to send arrays,  I think that one
>     got already done better on new approarch.  But we don't have support
>     for ifs (see hw/ide.c
>         if (s->identify_set) {
>          qemu_get_buffer(f, (uint8_t *)s->identify_data, 512);
>      }
>     Do we want support for things like that?

No.  We want fixed-sized sections, bonus points for a 'size' field in 
the header.  Just save everything unconditionally.  The current 
save/load functions do way too much stuff conditionally.  Saving a few 
bytes simply isn't worth the complexity of getting that right.

> d- how aggresive should the new design be?  i.e. be able to be compatible with
>     old design is good, or can we start with a clean sheet and just remove the
>     gotchas of the previous design?

Handle compatibility by keeping the old load functions and start over 
with a clean sheet.

cheers,
   Gerd

  parent reply	other threads:[~2009-08-19  7:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-18 13:34 [Qemu-devel] [PATCH RFC 0/5] New VMState table based load/save infrastructure Juan Quintela
2009-08-18 13:34 ` [Qemu-devel] [PATCH 1/5] loadvm already call vm_start() Juan Quintela
2009-08-18 13:34 ` [Qemu-devel] [PATCH 2/5] Don't call vm_start() if there was an error loading Juan Quintela
2009-08-18 13:34 ` [Qemu-devel] [PATCH 3/5] Don't ignore load_state() error return values Juan Quintela
2009-08-18 13:34 ` [Qemu-devel] [PATCH 4/5] New VMstate save/load infrastructure Juan Quintela
2009-08-18 17:13   ` Blue Swirl
2009-08-18 17:56     ` [Qemu-devel] " Juan Quintela
2009-08-19  7:49   ` [Qemu-devel] " Gerd Hoffmann
2009-08-19  9:38     ` [Qemu-devel] " Juan Quintela
2009-08-19 12:43       ` Gerd Hoffmann
2009-08-18 13:34 ` [Qemu-devel] [PATCH 5/5] Port apic to new VMState design Juan Quintela
2009-08-18 14:24   ` Reimar Döffinger
     [not found]   ` <20090818142405.GA16563@1und1.de>
     [not found]     ` <m37hx1tc9l.fsf@neno.mitica>
2009-08-18 15:21       ` [Qemu-devel] " Reimar Döffinger
2009-08-18 15:38         ` Juan Quintela
2009-08-18 16:06           ` Reimar Döffinger
2009-08-18 16:37             ` Juan Quintela
2009-08-19  8:00         ` Gerd Hoffmann
2009-08-19  9:10           ` Reimar Döffinger
     [not found]           ` <20090819085334.GA31062@1und1.de>
     [not found]             ` <4A8BC0C7.4010806@redhat.com>
2009-08-19  9:16               ` Reimar Döffinger
2009-08-19  7:41 ` Gerd Hoffmann [this message]
2009-08-19 10:15   ` [Qemu-devel] Re: [PATCH RFC 0/5] New VMState table based load/save infrastructure Juan Quintela
2009-08-19 12:55     ` Gerd Hoffmann

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=4A8BACBA.9020107@redhat.com \
    --to=kraxel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.