All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu-devel@nongnu.org, gleb@redhat.com
Subject: [Qemu-devel] Re: optional feature
Date: Wed, 16 Sep 2009 15:31:31 +0200	[thread overview]
Message-ID: <m33a6nnhho.fsf@neno.mitica> (raw)
In-Reply-To: <20090916122901.GA4729@redhat.com> (Michael S. Tsirkin's message of "Wed, 16 Sep 2009 15:29:01 +0300")

"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Wed, Sep 16, 2009 at 02:13:06PM +0200, Juan Quintela wrote:
>> VMState rules are simple:
>> - Everything is explicit
>
> By the way, pci currently has cmask,
> which performs checking on load, making sure
> that load does not modify a constant field in config space,
> which can't change as a result of guest actions.
> If it does - migration fails.
>
> This is IMO much better and more robust than
> simply hoping that there are no bugs or that
> developers remember to increment a version
> number each time they change some field.

This one is going to be fixed.  Some kind of checksum that assures you
that you haven't added/removed any field of a vmstatedescription.  It is
not difficult to add, but no code/whatever is there.

The only minimal check that it does today is that you put:

VMSTATE_INT32_ARRAY_V(irq_state, PCIDevice, 4, 2),

4 is the length and 2 is the version.

VMstate checks that PCIDevice has an irq_state field of type int32_t
with lenght 4.  I could have calculated the 4, but it is there just in
case someone changes the size of the array in PCIDevice, it gets a
compilation error.  There is not more infrastructure yet to check for
changes on the state.  It should come once devices are ported to
VMState.


> I think it's pretty important to keep this
> feature, and maybe add something similar
> to other devices.
>
> How will VMState support this?

This is the 1st request that I have.  This is what the code does today
(it is the same that was before):


static int get_pci_config_device(QEMUFile *f, void *pv, size_t size)
{
    PCIDevice *s = container_of(pv, PCIDevice, config);
    uint8_t config[size];
    int i;

    qemu_get_buffer(f, config, size);
    for (i = 0; i < size; ++i)
        if ((config[i] ^ s->config[i]) & s->cmask[i] & ~s->wmask[i])
            return -EINVAL;
    memcpy(s->config, config, size);

    pci_update_mappings(s);

    return 0;
}

/* just put buffer */
static void put_pci_config_device(QEMUFile *f, void *pv, size_t size)
{
    const uint8_t *v = pv;
    qemu_put_buffer(f, v, size);
}

i.e. at save time, we save everything that we want to save.
At load time, we only copy some things.  I don't understand what cmask
and wmask means, but I guess you understand this part better than me.

If we need to add more checks on load, we can just hack on that function
whatever you want to check/change/...

VMstate don't really care (as it shouldn't)

Later, Juan.

  reply	other threads:[~2009-09-16 13:31 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
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 [this message]
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=m33a6nnhho.fsf@neno.mitica \
    --to=quintela@redhat.com \
    --cc=gleb@redhat.com \
    --cc=mst@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.