Re: [PATCH v3 03/17] migration: Block migration comment or code is wrong

From: Avihai Horon <avihaih@nvidia.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>,
	qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Eric Farman <farman@linux.ibm.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	David Hildenbrand <david@redhat.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Thomas Huth <thuth@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>, Fam Zheng <fam@euphon.net>,
	Eric Blake <eblake@redhat.com>, John Snow <jsnow@redhat.com>,
	qemu-s390x@nongnu.org, qemu-block@nongnu.org,
	Kunkun Jiang <jiangkunkun@huawei.com>,
	"Zhang, Chen" <chen.zhang@intel.com>,
	Yishai Hadas <yishaih@nvidia.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Maor Gottlieb <maorg@nvidia.com>, Shay Drory <shayd@nvidia.com>,
	Kirti Wankhede <kwankhede@nvidia.com>,
	Tarun Gupta <targupta@nvidia.com>,
	Joao Martins <joao.m.martins@oracle.com>
Subject: Re: [PATCH v3 03/17] migration: Block migration comment or code is wrong
Date: Mon, 21 Nov 2022 09:21:23 +0200	[thread overview]
Message-ID: <58611bc7-e05e-7be9-00eb-b92696c5df3b@nvidia.com> (raw)
In-Reply-To: <88bcb40d-0ec0-e991-dd89-deb241a3063c@nvidia.com>

Ping.

On 10/11/2022 15:38, Avihai Horon wrote:
>
> On 08/11/2022 20:36, Vladimir Sementsov-Ogievskiy wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 11/3/22 19:16, Avihai Horon wrote:
>>> From: Juan Quintela <quintela@redhat.com>
>>>
>>> And it appears that what is wrong is the code. During bulk stage we
>>> need to make sure that some block is dirty, but no games with
>>> max_size at all.
>>
>> :) That made me interested in, why we need this one block, so I 
>> decided to search through the history.
>>
>> And what I see? Haha, that was my commit 04636dc410b163c 
>> "migration/block: fix pending() return value" [1], which you actually 
>> revert with this patch.
>>
>> So, at least we should note, that it's a revert of [1].
>>
>> Still that this will reintroduce the bug fixed by [1].
>>
>> As I understand the problem is (was) that in block_save_complete() we 
>> finalize only dirty blocks, but don't finalize the bulk phase if it's 
>> not finalized yet. So, we can fix block_save_complete() to finalize 
>> the bulk phase, instead of hacking with pending in [1].
>>
>> Interesting, why we need this one block, described in the comment you 
>> refer to? Was it an incomplete workaround for the same problem, 
>> described in [1]? If so, we can fix block_save_complete() and remove 
>> this if() together with the comment from block_save_pending().
>>
> I am not familiar with block migration.
> I can drop this patch in next version.
>
> Juan/Stefan, could you help here?
>
>>>
>>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>>> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
>>> ---
>>>   migration/block.c | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/migration/block.c b/migration/block.c
>>> index b3d680af75..39ce4003c6 100644
>>> --- a/migration/block.c
>>> +++ b/migration/block.c
>>> @@ -879,8 +879,8 @@ static void block_save_pending(void *opaque, 
>>> uint64_t max_size,
>>>       blk_mig_unlock();
>>>
>>>       /* Report at least one block pending during bulk phase */
>>> -    if (pending <= max_size && !block_mig_state.bulk_completed) {
>>> -        pending = max_size + BLK_MIG_BLOCK_SIZE;
>>> +    if (!pending && !block_mig_state.bulk_completed) {
>>> +        pending = BLK_MIG_BLOCK_SIZE;
>>>       }
>>>
>>>       trace_migration_block_save_pending(pending);
>>
>> -- 
>> Best regards,
>> Vladimir
>>