On 2014/12/10 18:39, Dr. David Alan Gilbert wrote:
> * Juan Quintela (quint...@redhat.com) wrote:
>> <arei.gong...@huawei.com> wrote:
>>> From: ChenLiang <chenlian...@huawei.com>
>>>
>>> Signed-off-by: ChenLiang <chenlian...@huawei.com>
>>> Signed-off-by: Gonglei <arei.gong...@huawei.com>
>>> Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
>>> ---
>>> arch_init.c | 8 +++-----
>>> 1 file changed, 3 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch_init.c b/arch_init.c
>>> index 846e4c5..0d0ba4a 100644
>>> --- a/arch_init.c
>>> +++ b/arch_init.c
>>> @@ -376,11 +376,8 @@ static int save_xbzrle_page(QEMUFile *f, uint8_t
>>> **current_data,
>>>
>>> prev_cached_page = get_cached_data(XBZRLE.cache, current_addr);
>>>
>>> - /* save current buffer into memory */
>>> - memcpy(XBZRLE.current_buf, *current_data, TARGET_PAGE_SIZE);
>>> -
>>
>> I think this is wrong.
>> Remember that now migration is done in parallel with the guest running.
>> If the guest modifies the page while we are encoding it, we end with a
>> different contents in the cache and in the real page, and that causes
>> corruption.
>>
>> This way, what we encoded is a "private copy of the page, so we don't
>> have that problem".
>>
>> Makes sense?
>
> Kind of; see back in March I hit this while testing the 1st version of this
> patch:
> https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg05631.html
>
> but then we had some patches that fixed it; and the discussion was here:
> https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg05677.html
> and then I summarized it as:
> https://lists.gnu.org/archive/html/qemu-devel/2014-03/msg05768.html
>
> * It's an interesting, if unusual, observation; it means we can send
> * completely bogus data at this point because we know it will get
> * overwritten later; I think the requirements are:
> *
> * 1) That we meet the protocol (which seems to require that the run lengths
> are
> * not allowed to be 0)
> * 2) That we don't get stuck in any loops or go over the end of the page
> * (I think this means we have to be careful of those byte loops within
> * the word-at-a-time cases)
> * 3) The page that ends up in our xbzrle cache must match the destination
> * page, since the next cycle of xbzrle will use it as reference.
> *
>
> Dave
>
Hi
The content that is discussed above is helpful to understand
the principle of xbzrle. Do you mind that I add it into xbzrle.txt?
Best regards
ChenLiang
>>> /* XBZRLE encoding (if there is no overflow) */
>>> - encoded_len = xbzrle_encode_buffer(prev_cached_page,
>>> XBZRLE.current_buf,
>>> + encoded_len = xbzrle_encode_buffer(prev_cached_page, *current_data,
>>> TARGET_PAGE_SIZE,
>>> XBZRLE.encoded_buf,
>>> TARGET_PAGE_SIZE);
>>> if (encoded_len == 0) {
>>> @@ -399,7 +396,8 @@ static int save_xbzrle_page(QEMUFile *f, uint8_t
>>> **current_data,
>>>
>>> /* we need to update the data in the cache, in order to get the same
>>> data */
>>> if (!last_stage) {
>>> - memcpy(prev_cached_page, XBZRLE.current_buf, TARGET_PAGE_SIZE);
>>> + xbzrle_decode_buffer(XBZRLE.encoded_buf, encoded_len,
>>> prev_cached_page,
>>> + TARGET_PAGE_SIZE);
>>> }
>>>
>>> /* Send XBZRLE based compressed page */
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
> .
>
