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] 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: Sun, 25 Mar 2007 13:27:04 +0100
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 25 Mar 2007 05:26:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070325114128.GA5950@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: Acdu2OUoI47vrNrMEduGdgAX8io7RQ==
Thread-topic: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
User-agent: Microsoft-Entourage/
On 25/3/07 12:41, "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx> wrote:

> Actually looking into it further for ia64 there is still a problem.
> We use large pages for the identity mapping on ia64.  In order to
> modify the PTE we'd have to break the large pages.
> Am I missing something obvious?


Actually I changed my mind -- your original scheme (strip the original
pseudophysical frame of its RAM, and add that original pseudophys frame into
the netback set of frames) has the very nice advantage that we don't end up
with queued packets taking space in the netback frame pool. I missed that
your scheme essentially switches the roles of a normal RAM frame and a
netback frame, so that you end up with a freed-up netback frame at the end
of the swap. Sorry about that.

So we're back to the problem of doing this switch when Xen is doing the p2m
translation (as on ia64 for example). On x86 we have a XENMEM_add_to_physmap
hypercall. This could be generalised to other architectures and extended.
For example, we could add a XENMAPSPACE_gpfn -- which would mean take the
'thing' currently mapped at the specified gpfn and map it at the new gpfn
location instead. I'd certainly personally rather see add_to_physmap()
extended than add extra single-purpose crap to the grant-table interfaces.

 -- Keir

Xen-devel mailing list

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