[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.