[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 Sun, Mar 25, 2007 at 01:27:04PM +0100, Keir Fraser wrote:
> 
> So we're back to the problem of doing this switch when Xen is doing the p2m
> translation (as on ia64 for example). On x86 we have a XENMEM_add_to_physmap
> hypercall. This could be generalised to other architectures and extended.
> For example, we could add a XENMAPSPACE_gpfn -- which would mean take the
> 'thing' currently mapped at the specified gpfn and map it at the new gpfn
> location instead. I'd certainly personally rather see add_to_physmap()
> extended than add extra single-purpose crap to the grant-table interfaces.

I've had a look at this and it seems that

1) We don't have the underlying operations suited for this.

We need something that can replace a p2m entry atomically and more
importantly swap two p2m entries rather than setting one and unmapping
the other.  The former is because we can't easily process p2m page
faults in the guest.  The latter is because we stlil need to unmap the
grant table entry after this operation so we have to keep the entry
around.

This is actually one of the reasons I picked the grant tables interface
originally in that we could unmap it at the same time rather than doing
a full swap followed by an unmap.

So are you OK with adding underlying operations that allows a full swap
of two p2m entries? This would then be used as follows in translated mode:

        a) new_addr = alloc_page
        b) memcpy(new_addr, addr, len)
        c) p2m_swap(__pa(new_addr), __pa(addr))
        d) grant_unmap(__pa(new_addr))

2) I'm unsure what you want me to do for non-translated mode, i.e., x86.

Are you happy with the new grant table operation or do you want to follow
a swap mode as above? The swapping code would look like:

        a) new_addr = alloc_page
        b) memcpy(new_addr, addr, len)
        c) pte_swap(new_addr, addr)
        d) grant_unmap(new_addr)

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®.