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

Reply-to: quintela@redhat.com
Gerd Hoffmann <kraxel@redhat.com> wrote:
>> 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.

Liked it, will implement it in next round.

>> 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.

That is the reason that I wanted to maintain the ->info field.  See the
other email.

>> 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.

Problem with this is when things can be NULL :p
>From msix.c

    if (!(dev->cap_present & QEMU_PCI_CAP_MSIX)) {
        return;
    }

void msix_save(PCIDevice *dev, QEMUFile *f)
{
    unsigned n = dev->msix_entries_nr;

    qemu_put_buffer(f, dev->msix_table_page, n * MSIX_ENTRY_SIZE);
    qemu_put_buffer(f, dev->msix_table_page + MSIX_PAGE_PENDING, (n + 7) / 8);
}

msix_table_page is not NULL only if QEMU_PCI_CAP_MSIX is present.
I think that optional fields are needed, or a better way of dealing with
things like this.

>> 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.

Liked this idea, makes things way, way easier.  I was looking at
virtio_net_load() and had a head-ache.  With your approach, things
become really easy.

Thaks for the review, Juan

  reply	other threads:[~2009-08-19 10:17 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 ` [Qemu-devel] [PATCH RFC 0/5] New VMState table based load/save infrastructure Gerd Hoffmann
2009-08-19 10:15   ` Juan Quintela [this message]
2009-08-19 12:55     ` [Qemu-devel] " 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=m3my5wp0t4.fsf@neno.mitica \
    --to=quintela@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.