qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] postcopy migration hangs while loading virtio state


From: Christian Borntraeger
Subject: Re: [Qemu-devel] postcopy migration hangs while loading virtio state
Date: Mon, 3 Jul 2017 16:28:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

On 06/30/2017 06:31 PM, Dr. David Alan Gilbert wrote:
> * Christian Borntraeger (address@hidden) wrote:
>> On 04/26/2017 01:45 PM, Christian Borntraeger wrote:
>>
>>>> Hmm, I have a theory, if the flags field has bit 1 set, i.e. 
>>>> RAM_SAVE_FLAG_COMPRESS
>>>> then try changing ram_handle_compressed to always do the memset.
>>>
>>> FWIW, changing ram_handle_compressed to always memset makes the problem go 
>>> away.
>>
>> It is still running fine now with the "always memset change"
> 
> Did we ever nail down a fix for this; as I remember Andrea said
> we shouldn't need to do that memset, but we came to the conclusion
> it was something specific to how s390 protection keys worked.

It was specific to s390. Newer Linuxes do not use the storage keys,
so we enable them lazily. If a guest goes from keyless to keyed, the
kernel will mark the VM to no longer use the zero page and the  walk all
pages of that guests and zaps the empty_zero page from the page table.
All normal code will then fault in a cow copy of the zero page on the
next access. 
The postcopy logic now at least reads all zero pages to prevent faults
on these addresses. If a running guest switches to key-mode afterwards
(but during postcopy) then we might get a fault for a zero page.

Still not sure about the best solution. (see  s390_enable_skey in 
arch/s390/mm/gmap.c)




reply via email to

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