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 17:44:51 +1000
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Mar 2007 00:44:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C22E8817.4DCC%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: <20070327033442.GD32121%yamahata@xxxxxxxxxxxxx> <C22E8817.4DCC%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Tue, Mar 27, 2007 at 08:36:39AM +0100, Keir Fraser wrote:
> 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.

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))

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>