qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 0/2][RFC] postcopy migration: Linux char device for postcopy
Date: Mon, 02 Jan 2012 18:55:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

On 01/02/2012 06:05 PM, Andrea Arcangeli wrote:
On Thu, Dec 29, 2011 at 06:01:45PM +0200, Avi Kivity wrote:
On 12/29/2011 06:00 PM, Avi Kivity wrote:
The NFS client has exactly the same issue, if you mount it with the intr
option.  In fact you could use the NFS client as a trivial umem/cuse
prototype.

Actually, NFS can return SIGBUS, it doesn't care about restarting daemons.

During KVMForum I suggested to a few people that it could be done
entirely in userland with PROT_NONE.

Or MAP_NORESERVE.

Anything you do that is CUSE-based should be doable in a separate QEMU thread (rather than a different process that talks to CUSE). If a userspace CUSE-based solution could be done with acceptable performance, the same thing would have the same or better performance if done entirely within QEMU.

So the problem is if we do it in
userland with the current functionality you'll run out of VMAs and
slowdown performance too much.

But all you need is the ability to map single pages in the address
space.

Would this also let you set different pgprots for different pages in the same VMA? It would be useful for write barriers in garbage collectors (such as boehm-gc). These do not have _that_ many VMAs, because every GC cycles could merge all of them back to a single VMA with PROT_READ permissions; however, they still put some strain on the VM subsystem.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]