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/
Home Products Support Community News


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

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/3] [RFC] User-space grant table device
From: Derek Murray <Derek.Murray@xxxxxxxxxxxx>
Date: Mon, 19 Mar 2007 14:31:05 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Comments: In-reply-to Keir Fraser <keir@xxxxxxxxxxxxx> message dated "Mon, 19 Mar 2007 14:00:29 +0000."
Delivery-date: Mon, 19 Mar 2007 07:30:11 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C22447FD.BCE1%keir@xxxxxxxxxxxxx>
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: <C22447FD.BCE1%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Keir Fraser wrote:
> 1. The patches are malformed (don't apply). It might be best to send the
> patches at plain-text attachments to prevent mangling by your email client.
> 2. Dependencies should be listed in the right order. So your patch 3 should
> be patch 1, since it is required by the grant-table device.

Sorry about those: I'll fix them in a subsequent repost.

> 3. Just looking at linux-changes.patch, I think the new interface function's
> semantics need to be clearer. Do you really mean for the hook function to be
> called *and* for unmap_page_range() to do the usual zap_pud_range() work?
> Should the hook function return anything? What about responsibility for
> synchronising TLBs?

Might it be better to replace this hook with something that operates on the PTE 
(rather than vm_area) level? Thus the hook could be called from 
zap_pte_range(), and this would harness all the TLB synchronisation that is 
normally employed.

I'm not sure that the hook function should return anything: as far as I 
understand, the unmap-grant hypercall should not fail, and, if it does, I don't 
see how we can recover from that.



Xen-devel mailing list