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: 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 19:20:29 +1000
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Mar 2007 02:19:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C22E94E3.4E75%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: <20070327081352.GA24634@xxxxxxxxxxxxxxxxxxx> <C22E94E3.4E75%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Tue, Mar 27, 2007 at 09:31:15AM +0100, Keir Fraser wrote:
> 
> > I was actually thinking of Jose's scheme where it's mapped in on
> > demand.  So you would still do your grant table map operation,
> > but instead of mapping it in as we do now it would simply notify
> > the hypervisor of the intention to map this page, and the hypervisor
> > can then map it in when it actually faults.
> 
> That's not quite how Jose's patch works. The lazy mapping is done by the
> guest in his patch.

That would mean the breaking of large pages on ia64 or any other
platform that uses them.  Is there any benefit for not doing it
in the hypervisor?

> If we're not going to go as far as supporting guest-visible 'p2m faults'
> then I think overall your original patch is probably the best approach so
> far. If I view the new hypercall as a special case of the existing unmap
> (which is an unmap-to-zero-pte special case) then it's not so bad. At least
> there should be very little new code in the hypervisor needed to implement
> it. We have a little while longer to think about this since the patches
> aren't for 3.0.5.

OK.  How do you want to proceed from here then?

Cheers,
-- 
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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