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] RFC: [0/2] Remove netloop by lazy copying in netback

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 27 Mar 2007 02:02:39 +0100
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 26 Mar 2007 18:00:36 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070327005233.GA19783@xxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdwC51W270pOdv+Edu/NgAWy6hiGQ==
Thread-topic: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
User-agent: Microsoft-Entourage/11.3.3.061214
On 27/3/07 01:52, "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx> wrote:

> It sounds good but looking further there is still an issue.
> 
> The problem is that the gpfn itself is not sufficient if we want to
> release the grant table entry.  We need to have the grant handle too
> in order to free the entry completely.  If we did provide the handle
> then this will just be the same operation that I was trying to add
> except that now we're adding it under XENMEM_add_to_physmap :)

Well, it could be a bit more work to change, but what does a p2m entry look
like for a grant mapping? The p2m table should be a very convenient place to
have typed entries, with one of those types being grant-mapping, and
including the maptrack handle. The MFN can be derived from the maptrack
handle where that is required. This would then conveniently be enough
information to perform implicit unmaps (the lack of support of which is an
annoying limitation for non-auto-translate guests which it would be really
nice to avoid for auto-translate guests, particularly since it ought to be
not really all that hard afaics).

This is pretty much the avenue (hopefully not a dead end!) that I pushed
Isaku Yamahata down when he queried physmap semantics a week or so ago.
Sadly we've had no need for grant mappings in x86 auto-translate guests yet,
so there's no example x86 implementation to lead the way. :-)

 -- Keir



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

<Prev in Thread] Current Thread [Next in Thread>