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: Fri, 23 Mar 2007 10:32:37 +0000
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 23 Mar 2007 03:32:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070323031757.GA16250@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: AcdtNpNI0hsXKtkpEduVTwAX8io7RQ==
Thread-topic: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback
User-agent: Microsoft-Entourage/11.2.5.060620
On 23/3/07 03:17, "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx> wrote:

> a) would be good but it doesn't look easy.  The reason is that we have
> to fit the result into skb frags which takes a page_struct and kmaps it
> on demand.  In other words once the skb is in injected into the stack
> the pseudo-physical address has to remain fixed whether we have a grant
> table entry mapped there or not.
> 
> So changing the guest PTE in the auto-translted case (ia64/ppc and EPT/NPT
> in future) isn't possible.

It still sounds like it would work. The fragment's 'struct page *' will map
to a particular kernel virtual addres. That kernel virtual address can be
transformed by arithmetic back to the 'struct page *'. The fact that the pte
that maps that kernel virtual address actually points over at some other
poor unsuspecting pfn (which already has a struct page *, thank you very
much) doesn't actually matter, does it? Does anyone ever go look at the pte
contents and try to work out the 'struct page *' from that? I doubt it -- or
our netback driver would not work right now on x86 (as the mach-to-phys
entry is garbage from the p.o.v. of dom0, so any attempt to translate the
pte contents into something meaningful in pseudophys space would fail).

PS. I've stripped my name from the To/Cc lists! :-)

 -- Keir



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

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