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: Tue, 27 Mar 2007 09:12:09 +0100
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Mar 2007 01:10:13 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070327074451.GA24369@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: AcdwR51027wjvtw6EduuUwAWy6hiGQ==
Thread-topic: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
User-agent: Microsoft-Entourage/
On 27/3/07 08:44, "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx> wrote:

> There is another way.  Instead of expanding add_to_physmap which
> doesn't quite fit our semantics, let's add a new operation that
> *actually* swaps two p2m entries.  Then it can be used as follows:
>         a) new_addr = alloc_page
>         b) memcpy(new_addr, addr, len)
>         c) p2m_swap(__pa(new_addr), __pa(addr))
>         d) grant_unmap(__pa(new_addr))

I like this a bit more than the grant-table hypercall, mainly because I
suspect the hypercall implementation is simpler. I'm not sure how easy it is
to make atomic though! Would there be enough locking to ensure that one of
the p2m entries being present in both (or neither) locations at some
intermediate point in time would not matter?

 -- Keir

Xen-devel mailing list

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