From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54332) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bazpF-0006FI-Di for qemu-devel@nongnu.org; Sat, 20 Aug 2016 02:32:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bazpA-0001iB-CG for qemu-devel@nongnu.org; Sat, 20 Aug 2016 02:32:12 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:28810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bazp9-0001hZ-N2 for qemu-devel@nongnu.org; Sat, 20 Aug 2016 02:32:08 -0400 References: <1452169208-840-1-git-send-email-zhang.zhanghailiang@huawei.com> <577B1238.7040605@huawei.com> <577B8BA7.6010001@huawei.com> <20160818155636.l46t4ha65eybnnhe@redhat.com> From: Hailiang Zhang Message-ID: <57B7F948.9040701@huawei.com> Date: Sat, 20 Aug 2016 14:31:36 +0800 MIME-Version: 1.0 In-Reply-To: <20160818155636.l46t4ha65eybnnhe@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 00/13] Live memory snapshot based on userfaultfd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli , Juan Quintela , dgilbert@redhat.com, Amit Shah Cc: peter.huangpeng@huawei.com, Baptiste Reynal , qemu list , hanweidong@huawei.com, Christian Pinto , colo-ft@hotmail.com Hi, I updated this series, but didn't post it, because there are some problems while i tested the snapshot function. I didn't know if it is the userfaultfd issue or not. I don't have time to investigate it this month. I have put them in github https://github.com/coloft/qemu/tree/snapshot-v2 Anyone who want to test and modify it are welcomed! Besides, will you join the linuxcon or KVM forum in Canada ? I wish to see you there if you join the conference ;) Thanks, Hailiang On 2016/8/18 23:56, Andrea Arcangeli wrote: > Hello everyone, > > I've an aa.git tree uptodate on the master & userfault branch (master > includes other pending VM stuff, userfault branch only contains > userfault enhancements): > > https://git.kernel.org/cgit/linux/kernel/git/andrea/aa.git/log/?h=userfault > > I didn't have time to test KVM live memory snapshot on it yet as I'm > still working to improve it. Did anybody test it? However I'd be happy > to take any bugreports and quickly solve anything that isn't working > right with the shadow MMU. > > I got positive report already for another usage of the uffd WP support: > > https://medium.com/@MartinCracauer/generational-garbage-collection-write-barriers-write-protection-and-userfaultfd-2-8b0e796b8f7f > > The last few things I'm working on to finish the WP support are: > > 1) pte_swp_mkuffd_wp equivalent of pte_swp_mksoft_dirty to mark in a > vma->vm_flags with VM_UFFD_WP set, which swap entries were > generated while the pte was wrprotected. > > 2) to avoid all false positives the equivalent of pte_mksoft_dirty is > needed too... and that requires spare software bits on the pte > which are available on x86. I considered also taking over the > soft_dirty bit but then you couldn't do checkpoint restore of a > JIT/to-native compiler that uses uffd WP support so it wasn't > ideal. Perhaps it would be ok as an incremental patch to make the > two options mutually exclusive to defer the arch changes that > pte_mkuffd_wp would require for later. > > 3) prevent UFFDIO_ZEROPAGE if registering WP|MISSING or trigger a > cow in userfaultfd_writeprotect. > > 4) WP selftest > > In theory things should work ok already if the userland code is > tolerant against false positives through swap and after fork() and > KSM. For an usage like snapshotting false positives shouldn't be an > issue (it'll just run slower if you swap in the worst case), and point > 3) above also isn't an issue because it's going to register into uffd > with WP only. > > The current status includes: > > 1) WP support for anon (with false positives.. work in progress) > > 2) MISSING support for tmpfs and hugetlbfs > > 3) non cooperative support > > Thanks, > Andrea > > . >