forked from luck/tmp_suning_uos_patched
fa41ba0d08
Right now there is a potential hang situation for postcopy migrations, if the guest is enabling storage keys on the target system during the postcopy process. For storage key virtualization, we have to forbid the empty zero page as the storage key is a property of the physical page frame. As we enable storage key handling lazily we then drop all mappings for empty zero pages for lazy refaulting later on. This does not work with the postcopy migration, which relies on the empty zero page never triggering a fault again in the future. The reason is that postcopy migration will simply read a page on the target system if that page is a known zero page to fault in an empty zero page. At the same time postcopy remembers that this page was already transferred - so any future userfault on that page will NOT be retransmitted again to avoid races. If now the guest enters the storage key mode while in postcopy, we will break this assumption of postcopy. The solution is to disable the empty zero page for KVM guests early on and not during storage key enablement. With this change, the postcopy migration process is guaranteed to start after no zero pages are left. As guest pages are very likely not empty zero pages anyway the memory overhead is also pretty small. While at it this also adds proper page table locking to the zero page removal. Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Acked-by: Janosch Frank <frankja@linux.vnet.ibm.com> Cc: stable@vger.kernel.org Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> |
||
|---|---|---|
| .. | ||
| cmm.c | ||
| dump_pagetables.c | ||
| extmem.c | ||
| fault.c | ||
| gmap.c | ||
| gup.c | ||
| hugetlbpage.c | ||
| init.c | ||
| maccess.c | ||
| Makefile | ||
| mem_detect.c | ||
| mmap.c | ||
| page-states.c | ||
| pageattr.c | ||
| pgalloc.c | ||
| pgtable.c | ||
| vmem.c | ||