All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Mario Smarduch <m.smarduch@samsung.com>
Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: huge 2nd stage pages and live migration
Date: Fri, 28 Mar 2014 12:17:36 -0700	[thread overview]
Message-ID: <20140328191736.GK25519@cbox> (raw)
In-Reply-To: <5335B3CD.30207@samsung.com>

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

      reply	other threads:[~2014-03-28 19:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-28 17:39 huge 2nd stage pages and live migration Mario Smarduch
2014-03-28 19:17 ` Christoffer Dall [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140328191736.GK25519@cbox \
    --to=christoffer.dall@linaro.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=m.smarduch@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.