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

xen-devel

[Top] [All Lists]

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: 2007年3月27日 21:09:30 +1000
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: 2007年3月27日 04:08:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C22EB310.C477%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: <20070327102524.GA25582@xxxxxxxxxxxxxxxxxxx> <C22EB310.C477%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Tue, Mar 27, 2007 at 11:40:00AM +0100, Keir Fraser wrote:
>
> Yeah, but: how does Xen efficiently work out whether a not-present fault is
> due to a lazy grant mapping and, if so, what it is that needs to be demand
> mapped? PV guests can store what they like in not-present pagetable entries.
> Perhaps we could make use of reserved bits in ptes instead (not that there
> are any in non-pae x86, but I'd very much like to obsolete non-pae x86 Xen
> after 3.0.5 anyway -- I don't think anyone actually ships a product with
> non-pae bits).
That's a good point. Actually, on x86 we have the accessed bit so
we can do this in a different way.
Instead of setting up PTE/P2M entries that cause a page fault on the
first access, we setup the real thing every time and simply check the
accessed bit when we unmap the grant table entry. That will then allow
us to flush the TLB iff the accessed bit is set.
Now I haven't looked at the other architectures, but I would think
the accessed bit would likely to be present there as well, do you
know whether this is the case for ia64/ppc?
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>
Previous by Date: Re: [Xen-devel] System time monotonicity , Keir Fraser
Next by Date: Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback , Herbert Xu
Previous by Thread: Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback , Keir Fraser
Next by Thread: Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback , Keir Fraser
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /