From: Andrea Arcangeli <aarcange@redhat.com>
To: "Huangpeng (Peter)" <peter.huangpeng@huawei.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Pavel Hrdina <phrdina@redhat.com>,
Zhanghailiang <zhang.zhanghailiang@huawei.com>,
KVM devel mailing list <kvm@vger.kernel.org>,
Stefan Hajnoczi <stefanha@gmail.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [RFC]VM live snapshot proposal
Date: Wed, 5 Mar 2014 15:55:31 +0100 [thread overview]
Message-ID: <20140305145531.GR27866@redhat.com> (raw)
In-Reply-To: <615092B2FD0E7648B6E4B43E029BCFB84D57B4C7@SZXEMA503-MBS.china.huawei.com>
On Wed, Mar 05, 2014 at 01:52:14AM +0000, Huangpeng (Peter) wrote:
> Hi, Andrea
>
> Where can I get the dev-git-branch?
> I can use it to try the snapshot prototype coding.
You can find the current status in the origin/master branch here
http://git.kernel.org/cgit/linux/kernel/git/andrea/aa.git
however userlandfd is still missing so it's not yet good for
transparent userfault when it's O_DIRECT or other gup users triggering
the access (those would currently return an error to userland if they
hit on a userfault vma, and we don't want to change userland to ever
get an error or the modifications to userland are too big).
userlandfd will let the kernel wait on an event from the migration
thread and it will talk with the migration thread directly. So
userland won't be able to notice the userfault happening inside a
write() or kvm ioctl() syscall (you could notice only if you strace
the migration thread). That's more efficient too so the host scheduler
can directly switch to the migration thread without having to return
to userland first. And after remap_anon_pages completes and the host
scheduler runs the vcpu or I/O thread again, gup_fast can continue
from kernel mode where it stopped again without unnecessary exits to
userland. Making the kernel speak directly to the migration thread is
somewhat more tricky at the kernel level that what you find in aa.git
right now, but it is worth it to be transparent to all syscalls that
would trip on userfaults with gup_fast.
next prev parent reply other threads:[~2014-03-05 14:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-03 1:13 [Qemu-devel] [RFC]VM live snapshot proposal Huangpeng (Peter)
2014-03-03 12:32 ` Stefan Hajnoczi
2014-03-03 12:55 ` Kevin Wolf
2014-03-03 13:19 ` Paolo Bonzini
2014-03-03 13:30 ` Kevin Wolf
2014-03-03 13:47 ` Paolo Bonzini
2014-03-03 14:04 ` Kevin Wolf
2014-03-03 14:55 ` Dr. David Alan Gilbert
2014-03-03 19:52 ` Andrea Arcangeli
2014-03-04 1:35 ` Huangpeng (Peter)
2014-03-05 14:46 ` Andrea Arcangeli
2014-03-05 1:52 ` Huangpeng (Peter)
2014-03-05 14:55 ` Andrea Arcangeli [this message]
2014-03-04 1:28 ` Huangpeng (Peter)
2014-03-04 9:40 ` Dr. David Alan Gilbert
2014-03-05 1:00 ` Huangpeng (Peter)
2014-03-05 9:09 ` Paolo Bonzini
2014-03-06 1:42 ` Huangpeng (Peter)
2014-03-06 9:14 ` Dr. David Alan Gilbert
2014-03-04 1:06 ` Huangpeng (Peter)
2014-03-03 13:18 ` Paolo Bonzini
2014-03-04 1:02 ` Huangpeng (Peter)
2014-03-04 8:54 ` Stefan Hajnoczi
2014-03-04 9:05 ` Paolo Bonzini
2014-03-04 11:28 ` Wenchao Xia
2014-03-05 0:46 ` Huangpeng (Peter)
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=20140305145531.GR27866@redhat.com \
--to=aarcange@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.huangpeng@huawei.com \
--cc=phrdina@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=xiawenc@linux.vnet.ibm.com \
--cc=zhang.zhanghailiang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).