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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 27 Mar 2007 18:15:10 +1000
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Mar 2007 01:14:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C22E9069.4E6E%Keir.Fraser@xxxxxxxxxxxx>
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: <20070327074451.GA24369@xxxxxxxxxxxxxxxxxxx> <C22E9069.4E6E%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Tue, Mar 27, 2007 at 09:12:09AM +0100, Keir Fraser wrote:
> 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?

Well for my purpose I don't need both entries to be written atomically.
As long as each entry is replaced atomically wrt itself it'll be good
enough for the usage scenario above.

Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Xen-devel mailing list

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