huge 2nd stage pages and live migration

huge 2nd stage pages and live migration

[Mario Smarduch]

Hello

I've been working on live migration for ARM-KVM, and noticed
problem completing migration with huge 2nd stage tables.
 

Aafter write protecting the VM, for write fault 512 page bits
are set in dirty_bitmap[] to take into account future writes to 
huge page.The pmd is write protected again when QEMU  reads the 
dirty log, and the cycle repeats. With this not even a idle 
32MB VM  completes live migration.

If QEMU uses THPs, and 2nd stage tables use pte's, then there
is no problem, live migration is quick. I'm assumung QEMU and Guest 
huge pages with 2nd stage page table pte's should work fine too.

I'm wondering how this has been solved (for any architecture)? 

- Mario

Re: huge 2nd stage pages and live migration

[Christoffer Dall]

On Fri, Mar 28, 2014 at 10:39:25AM -0700, Mario Smarduch wrote:
> Hello
> 
> I've been working on live migration for ARM-KVM, and noticed
> problem completing migration with huge 2nd stage tables.
>  
> 
> Aafter write protecting the VM, for write fault 512 page bits
> are set in dirty_bitmap[] to take into account future writes to 
> huge page.The pmd is write protected again when QEMU  reads the 
> dirty log, and the cycle repeats. With this not even a idle 
> 32MB VM  completes live migration.
> 
> If QEMU uses THPs, and 2nd stage tables use pte's, then there
> is no problem, live migration is quick. I'm assumung QEMU and Guest 
> huge pages with 2nd stage page table pte's should work fine too.
> 
> I'm wondering how this has been solved (for any architecture)? 
> 
I don't know if there's a generic solution (have you looked at x86/PPC
what they do?), but I don't see any conceptual problem with putting the
VM into use-pte-for-2nd-stage-mappings-I'm-migrating-mode.

-Christoffer