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: 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:10:40 +0100
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Mar 2007 01:08:45 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070327075927.GA24511@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: AcdwR2hopsLrAtw6EduuUwAWy6hiGQ==
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 08:59, "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx> wrote:

>>> Also bear in mind the plan to avoid the grant mapping at all in the
>>> direct-to-wire transmit case. This also will rely on a #PF (or some other
>>> fault, potentially) if the guest tries to access that pseudophysical page of
>>> memory. If we can work out a way to make this work on ia64 then the
>>> delayed-copy implementation problems are solved too.
> 
> Even with this we could still keep the large pages by using page
> faults on the host page table rather than the guest page table.

Sure. How would you expose those to the guest? If that can be solved we can
define grant-table unmap to switch the p2m entry into an explicitly invalid
state and we're away.

 -- Keir



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

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