[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 Fri, Mar 23, 2007 at 10:32:37AM +0000, Keir Fraser wrote:
> 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).

You're right, it's not as bad as I thought.

I was worried about this because if anybody calls virt_to_page
or something equivalent on that virtual address they'll get
the old struct page/pseudo-physical address rather than the new
one.  However, this is OK because as long as the access is
within the guest they'll still have to convert it back to that
virtual address.

The only catch is that I wanted to have the same lazy-copy
mechanism for dom0=>domU.  In that case we can't rely on domU
to trigger the copy so dom0 (or the driver domain) will need
to initiate it.  The easiest way to do that from outside domU
is through changing its P2M table.

I suppose doing it this way doesn't necessarily preclude a
different solution for dom0=>domU.

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



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