From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: qemu-devel@nongnu.org
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>, Alexander Graf <agraf@suse.de>
Subject: [Qemu-devel] [RFC PATCH] vmstate: Enable custom migration block name check
Date: Mon, 25 Aug 2014 20:22:01 +1000 [thread overview]
Message-ID: <1408962121-8867-1-git-send-email-aik@ozlabs.ru> (raw)
This adds a callback to support custom names for migration blocks.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
RFC! not a real patch!
There was a problem a while ago how to migrate sPAPR TCE tables - they
needed unique id + instance_id and there 2 approaches for that:
1. Put them on a virtual made-up TCE bus, LIOBN (logical bus number) is
an unique ID and this would give TCE tables unique names like
liobn@80000000/spapr_iommu, instance id would always be 0.
vmstate_spapr_tce_table would be registered via DeviceClass::vmsd pointer.
2. Do not register vmsd via DeviceClass and use explicit call of
vmstate_register() using LIOBN as an instance id. This way TCE tables would
get "spapr_iommu" name and unique id == LIOBN.
Approach 2 is used by upstream.
Both 1 and 2 were suggested by maintainers :) However with 1 month delay
and I started using 1) in our internal build of "powerkvm".
In the current version of our internal "powerkvm" thing I used 2) as this
is what upstream uses.
The proposed patch is a part of a hack to allow migration
liobn@80000000/spapr_iommu + 0 to spapr_iommu + 80000000.
Is this too horrible to be considered as a patch for upstream?
I am not going to push the second part of the hack anyway.
Is there any other way to implement the hack I want without toching these files?
Thanks!
---
include/migration/vmstate.h | 1 +
savevm.c | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
index 2759908..86afd9a 100644
--- a/include/migration/vmstate.h
+++ b/include/migration/vmstate.h
@@ -134,6 +134,7 @@ struct VMStateDescription {
int (*pre_load)(void *opaque);
int (*post_load)(void *opaque, int version_id);
void (*pre_save)(void *opaque);
+ bool (*compat_name)(void *opaque, const char *idstr, int instance_id);
VMStateField *fields;
const VMStateSubsection *subsections;
};
diff --git a/savevm.c b/savevm.c
index 22123be..60e7dd8 100644
--- a/savevm.c
+++ b/savevm.c
@@ -731,6 +731,12 @@ static SaveStateEntry *find_se(const char *idstr, int instance_id)
instance_id == se->alias_id))
return se;
}
+
+ /* Migrating from a weird custom version? */
+ if (se->vmsd && se->vmsd->compat_name &&
+ se->vmsd->compat_name(se->opaque, idstr, instance_id)) {
+ return se;
+ }
}
return NULL;
}
--
2.0.0
next reply other threads:[~2014-08-25 10:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-25 10:22 Alexey Kardashevskiy [this message]
2014-08-25 10:23 ` [Qemu-devel] [RFC PATCH] vmstate: Enable custom migration block name check Alexander Graf
2014-08-25 11:16 ` Alexey Kardashevskiy
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=1408962121-8867-1-git-send-email-aik@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=agraf@suse.de \
--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 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).