From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@qumranet.com>
Subject: Re: [RFC] [VTD][patch 1/3] vt-d support for pci
 passthrough: kvm-vtd--kernel.patch
Date: Sun, 11 May 2008 18:31:23 +0300
Message-ID: <4827114B.1050209@qumranet.com>
References: <1FE6DD409037234FAB833C420AA843EC01438CB3@orsmsx424.amr.corp.intel.com>	<4820F845.3080704@codemonkey.ws>	<1FE6DD409037234FAB833C420AA843EC0147C07F@orsmsx424.amr.corp.intel.com>	<48210C51.7090206@codemonkey.ws>
	<4821434E.20504@qumranet.com> <48220168.3050907@codemonkey.ws>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: kvm-devel@lists.sourceforge.net,
	Chris Wright <chrisw@redhat.com>,
	"Kay,  Allen M" <allen.m.kay@intel.com>,
	Ben-Ami Yassour1 <benami@il.ibm.com>,
	Andrea Arcangeli <andrea@qumranet.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Return-path: <kvm-devel-bounces@lists.sourceforge.net>
In-Reply-To: <48220168.3050907@codemonkey.ws>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=kvm-devel>
List-Post: <mailto:kvm-devel@lists.sourceforge.net>
List-Help: <mailto:kvm-devel-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=subscribe>
Sender: kvm-devel-bounces@lists.sourceforge.net
Errors-To: kvm-devel-bounces@lists.sourceforge.net
List-Id: kvm.vger.kernel.org

Anthony Liguori wrote:
>> I don't think we can do page migration with VT-d.  You need to be able 
>> to detect whether the page has been changed by dma after you've copied 
>> it but before you changed the pte, but VT-d doesn't allow that AFAICT.
>>     
>
> Hrm, I would have to look at the VT-d but I suspect you're right.  
> That's unfortunate.
>
> That means mlock() isn't sufficient.  It also means that the VMAs can't 
> be updated while the guest is running.  Is there any way to lock a vma 
> region such that things like madvise/mmap(MAP_FIXED) will always fail?
>   

Userspace can simply not issue them.  Page migration is also controlled 
by userspace.

Once active memory defragmentation goes in, we need a way to tell the 
kernel that the allocation is unreclaimable, perhaps with a new mmap flag.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone