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: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, 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 08:36:39 +0100
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Mar 2007 00:35:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070327033442.GD32121%yamahata@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdwQqfg5rSxWtw1EduuUwAWy6hiGQ==
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 04:34, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx> wrote:

> The ia64 p2m entry is 64bit and some bits are already used
> so that there is no room for storing grant table related handle.
> I don't think storing the maptrack handle instead of MFN is good idea
> because it would make the p2m more complicated.
> 
> Is it possible to look up grant table reference by MFN effectively?
> Probably MFN-keyed hash table whose entry is struct active_grant_table.
> I'm not sure whether it is effective compared to guest providing
> grant refernece, though.

This is quite a shame, since the swap-grant-mapping-for-memory hypercall
simply is not very nice. What if we wanted to swap a grant mapping for
another grant mapping in future? Or some other kind of mapping? We end up
needing a new, complicated, grant-table hypercall every time. Or in six
months time we decide this wasn't such a good idea, implement another
scheme, but have this special-purpose grant-table hypercall hanging around
unused forever more.

Could we shatter the ia64 guest large mappings easily? They have no benefit
on Xen anyway apart from some inconsequential memory saving.

 -- Keir



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

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