WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 0/3] [RFC] User-space grant table device

To: "Derek Murray" <Derek.Murray@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/3] [RFC] User-space grant table device
From: "Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>
Date: Wed, 21 Mar 2007 06:16:39 -0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx, Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 21 Mar 2007 07:15:32 -0700
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=FsOPvrWs/UWupsUE71iF8R3XBhOZZ/gjjkA2697VHJXX40IiTJ22zyFEwZKET590ScuMoZELBbtD2t0NqcGgnBLn4X9leGkZJN3OUifpd+RONqzQ/9ntCwDkl2NqwESQYYONb+xJeUM9f/lPv3i4UZO4zKXtTUVS+mRPofHWjNE=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pSirYi1rqIVsYgWyEVfNtzxawl6570KTrzHq3lEAySJ2U0wup7MytNF+3WiVf+GF5HoLvEz9EmrQ2LzoTKqJFYmPCr6RNsycFqTWyVzmVKmEAzi08U5ToP1p2wWijVZP5Cl91lcHrU/xP+n/OhGVIiG6xlS6goK1nSoQMfoqIBo=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D453AE4A-8A09-4F59-8562-73301E10A654@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <F17DBCEF-7C4A-488D-90B8-DC783DC465E7@xxxxxxxxxxxx> <20070321043209.GA13105%yamahata@xxxxxxxxxxxxx> <D453AE4A-8A09-4F59-8562-73301E10A654@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Am I correct in thinking that the use of the VM_FOREIGN flag, plus
the use of vm_private_data to store an array of struct page pointers,
enables the pages to be mapped into user space using get_user_pages()
(which is called by make_pages_present(), which is called by
do_mmap_pgoff())? Or is it the call to vm_insert_page()?

Yes, VM_FOREIGN was added to allow get_user_pages to sort out where
the granted page was mapped in kernel and to identify the underlying
machine mapping.  As blktap uses zero-copy, this was necessary for aio
to map down appropriately and to arrange DMA directly to the guest
pages.  The Linux virtual memory code has churned a bunch since I
wrote that, so there may now be a better approach than the
dual-mapping and the special case in get_user_pages() to resolve them
-- then again, maybe not. ;)

I really like the early cleanup hook in your patches to cleanly unmap
any outstanding granted pages before zapping the range on vm area
destruction.  It's something that I've been wanting to do for a while
-- very stability-adding. ;)

a.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel