[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |