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@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 27 Mar 2007 20:25:24 +1000
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 27 Mar 2007 03:24:30 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C22EADD4.C466%keir@xxxxxxxxxxxxx>
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: <20070327100610.GA25437@xxxxxxxxxxxxxxxxxxx> <C22EADD4.C466%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Tue, Mar 27, 2007 at 11:17:40AM +0100, Keir Fraser wrote:
> 
> The grant-table code is pretty complicated and a harbour for bugs. So I
> prefer to keep it as small and simple as possible. I'm not sure the
> comparison with page-table operations is a good one -- the Xen PV interface
> for pagetable updates doesn't include anything as special-case as the things
> we are currently considering for grant tables.

Fair enough.  The only thing I could say in this regard is that if
we moved in this direction we could replace all existing grant table
ops with this and eventually phase them out.

> > As for a place to store the info, we can just store the real MFN in
> > the p2m table but mark it as not present.
> 
> We can't do that where there is no p2m. I suppose we could make this
> operation specific to auto-translate guests.

Actually we can just mark the PTEs as not present in that case.  The
hypervisor can then mark the PTEs as present on the first fault.

Just as grant table operations currently work on virtual addresses for
non-translated guests and physical addresses for translated guests,
such an operation would work on PTEs for non-translated guests and
p2m entries for translated guests.

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>