From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Alexander Graf <agraf@suse.de>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH] vmstate: Enable custom migration block name check
Date: Mon, 25 Aug 2014 21:16:08 +1000 [thread overview]
Message-ID: <53FB1AF8.7050503@ozlabs.ru> (raw)
In-Reply-To: <53FB0EB9.8090904@suse.de>
On 08/25/2014 08:23 PM, Alexander Graf wrote:
>
>
> On 25.08.14 12:22, Alexey Kardashevskiy wrote:
>> 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?
>
> Is there any reason you can't keep this patch in your downstream fork
> along with the user of it? :)
I can and most likely will. But someone else could benefit from it sometime
later, dunno, there are already manymany callbacks, why not one more :)
But mostly - I actually want to know if what patch does can be done without
it. Enormous amount of callbacks and flags tell me that it is possible, I
am just not smart enough to see it :)
--
Alexey
prev parent reply other threads:[~2014-08-25 11:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-25 10:22 [Qemu-devel] [RFC PATCH] vmstate: Enable custom migration block name check Alexey Kardashevskiy
2014-08-25 10:23 ` Alexander Graf
2014-08-25 11:16 ` Alexey Kardashevskiy [this message]
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=53FB1AF8.7050503@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 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.