All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Henrique Barboza <danielhb413@gmail.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: David Gibson <david@gibson.dropbear.id.au>
Subject: Question about vmstate_register(), dc->vmsd and instance_id
Date: Thu, 17 Mar 2022 10:58:56 -0300	[thread overview]
Message-ID: <38c43d66-e57c-e0fe-d35f-c411d40d6611@gmail.com> (raw)

Hi,

I've been looking into converting some vmstate_register() calls to use dc->vmsd,
using as a base the docs in docs/devel/migration.rst. This doc mentions that we
can either register the vmsd by using vmstate_register() or we can use dc->vmsd
for qdev-based devices.

When trying to convert this vmstate() call for the qdev alternative (hw/ppc/spapr_drc.c,
drc_realize()) I found this:

     vmstate_register(VMSTATE_IF(drc), spapr_drc_index(drc), &vmstate_spapr_drc,
                      drc);

spapr_drc_index() is an unique identifier for these DRC devices and it's being used
as instance_id. It is not clear to me how we can keep using this same instance_id when
using the dc->vmsd alternative. By looking a bit into migration files I understood
that if dc->vmsd is being used the instance_id is always autogenerated. Is that correct?

Another related question is the role of instance_id per se. I understand that this
value is used to identify SaveStateEntries in migration/savevm.c and it's autogenerated
if the caller does not provide it. And there's also this comment from
register_savevm_live():

/* TODO: Individual devices generally have very little idea about the rest
    of the system, so instance_id should be removed/replaced.
    Meanwhile pass -1 as instance_id if you do not already have a clearly
    distinguishing id for all instances of your device class. */

Given that this is a 13 year old comment from Anthony Liguori I wanted to confirm its
validity. Is there a long term goal of getting rid of instance_id? Can I ignore its
role when converting these calls to dc->vmsd?


Thanks,


Daniel


             reply	other threads:[~2022-03-17 14:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-17 13:58 Daniel Henrique Barboza [this message]
2022-03-17 15:04 ` Question about vmstate_register(), dc->vmsd and instance_id Peter Maydell
2022-03-17 16:29   ` Dr. David Alan Gilbert
2022-03-18  3:43     ` David Gibson
2022-03-18 19:51       ` Daniel Henrique Barboza
2022-03-19  9:43         ` David Gibson
2022-03-23 21:39     ` Daniel Henrique Barboza

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=38c43d66-e57c-e0fe-d35f-c411d40d6611@gmail.com \
    --to=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --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.