On Thu, Jan 09, 2020 at 10:50:25AM +0100, Juan Quintela wrote:
>Wei Yang wrote:
>> On Mon, Dec 16, 2019 at 10:35:39AM +0800, Wei Yang wrote:
>>>Would this one be picked up this time?
>>
>> Happy new year to all.
>>
>> Can I ask the plan for this patch set?
>
>queued
>
Thanks :-)
--
Wei Yang
Hel
Wei Yang wrote:
> On Mon, Dec 16, 2019 at 10:35:39AM +0800, Wei Yang wrote:
>>Would this one be picked up this time?
>
> Happy new year to all.
>
> Can I ask the plan for this patch set?
queued
>
>>
>>On Sat, Oct 26, 2019 at 07:19:58AM +0800, Wei Yang wrote:
>>>We don't support multifd during po
On Mon, Dec 16, 2019 at 10:35:39AM +0800, Wei Yang wrote:
>Would this one be picked up this time?
Happy new year to all.
Can I ask the plan for this patch set?
>
>On Sat, Oct 26, 2019 at 07:19:58AM +0800, Wei Yang wrote:
>>We don't support multifd during postcopy, but user still could enable
>>b
Would this one be picked up this time?
On Sat, Oct 26, 2019 at 07:19:58AM +0800, Wei Yang wrote:
>We don't support multifd during postcopy, but user still could enable
>both multifd and postcopy. This leads to migration failure.
>
>Patch 1 does proper cleanup, otherwise we may have data corruption
Ping for comments.
On Sat, Oct 26, 2019 at 07:19:58AM +0800, Wei Yang wrote:
>We don't support multifd during postcopy, but user still could enable
>both multifd and postcopy. This leads to migration failure.
>
>Patch 1 does proper cleanup, otherwise we may have data corruption.
>Patch 2 does the
We don't support multifd during postcopy, but user still could enable
both multifd and postcopy. This leads to migration failure.
Patch 1 does proper cleanup, otherwise we may have data corruption.
Patch 2 does the main job.
BTW, current multifd synchronization method needs a cleanup. Will send a
