From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoffer Dall Subject: Re: huge 2nd stage pages and live migration Date: Fri, 28 Mar 2014 12:17:36 -0700 Message-ID: <20140328191736.GK25519@cbox> References: <5335B3CD.30207@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org To: Mario Smarduch Return-path: Received: from mail-pa0-f52.google.com ([209.85.220.52]:49817 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751902AbaC1TRV (ORCPT ); Fri, 28 Mar 2014 15:17:21 -0400 Received: by mail-pa0-f52.google.com with SMTP id rd3so5416449pab.25 for ; Fri, 28 Mar 2014 12:17:21 -0700 (PDT) Content-Disposition: inline In-Reply-To: <5335B3CD.30207@samsung.com> Sender: kvm-owner@vger.kernel.org List-ID: 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