From: "Michael S. Tsirkin" <mst@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>
Subject: [Qemu-devel] Re: optional feature
Date: Wed, 16 Sep 2009 15:37:10 +0300 [thread overview]
Message-ID: <20090916123710.GB4729@redhat.com> (raw)
In-Reply-To: <m37hvzt6r1.fsf@neno.mitica>
On Wed, Sep 16, 2009 at 02:26:58PM +0200, Juan Quintela wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Wed, Sep 16, 2009 at 02:14:32PM +0200, Juan Quintela wrote:
> >> >> See below, we are changing the state to one table, and tables don't have
> >> >> neither if's or whiles (we have a limited for that just walks arrays).
> >> >
> >> > Let's just bite the bullet and add support for if's? It's not like it's
> >> > hard to invent 'struct vmstate_condition' or some such.
> >>
> >> I have to do it. The problem is not adding an optional field, is adding
> >> it conditionally on _what_, and that _what_ should also be ideally on vmstate.
> >>
> >> Later, Juan.
> >
> > pci config is on vmstate already, I don't see a problem here.
>
> vmstate don't understand pci config.
How can it save it then? What's more, how can it load it sanely? E.g.
when loading we must make sure that device id etc match.
> I want to manipulate images with
> the informantion that you have given vmstate. Sending another byte
> meaning:
>
> msix_enabled
>
> and now depending on that value another field is ok with me.
1. this bit is there in config already.
sending it twice is redundant and so, wrong:
we will just have to add even more code
to check that these values match
2. it's also not backward compatible, is it?
> You can
> calculate msix_enable at pre_save time whenever way that you see fit.
Not everything has to fit in a global variable, we can have a table
per-device. Then each time msix_enable bit is changed, I can tell
vmstate about it.
> What vmstate needs is a only to now if msix_enable is 0 or 1, how you
> calculate it, VMState don't care.
Add a condition including offset into pci config and bitmask?
> Later, Juan.
next prev parent reply other threads:[~2009-09-16 12:39 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 [this message]
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
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=20090916123710.GB4729@redhat.com \
--to=mst@redhat.com \
--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).