[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 0/5] New VMState table based load/save infra

From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH RFC 0/5] New VMState table based load/save infrastructure
Date: Wed, 19 Aug 2009 09:41:46 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]