qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH] vmstate: Enable custom migration block name


From: Alexey Kardashevskiy
Subject: Re: [Qemu-devel] [RFC PATCH] vmstate: Enable custom migration block name check
Date: Mon, 25 Aug 2014 21:16:08 +1000
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

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 <address@hidden>
>> ---
>>
>> 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
>> address@hidden/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
>> address@hidden/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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]