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: Fri, 23 Mar 2007 14:17:57 +1100
Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <keir@xxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 22 Mar 2007 20:17:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C228540B.C122%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: <20070322105055.GA8918@xxxxxxxxxxxxxxxxxxx> <C228540B.C122%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Thu, Mar 22, 2007 at 03:40:59PM +0000, Keir Fraser wrote:
> 
> I didn't look super closely at the precise set of steps on x86 either. Do
> you take a normal page of memory in the guest's address space and simply
> give it an extra mapping in the netback area? Or do you take a page with no
> pseudophysical address and assign it a pseudophysical address corresponding
> to its place in the netback area?

I allocate a new page in dom0, i.e., an mfn/pfn pair, take away the mfn
and give it to the original netback pfn which would have no mfn after
the grant table entry has been unmapped.  The newly mfn-less pfn is
then put back into the netback area in the place of the old one which
is now a normal page.

> I certainly assumed (a), and I think that would work fine on ia64 and
> powerpc, as the page would already have a pseudophysical address?

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.  As we either have to change the guest PTE or
the host P2M, this leaves us with only the latter as an option.  We can't
do that currently as the hypervisor doesn't have such an operation.

So it looks like we'll need a new hypercall (although not a grant table
operation) to do it this way on an auto-translated dom0.

PS Check out the To/Cc fields, the number of Keirs is getting out of
control :)

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>