[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


  • To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Fri, 23 Mar 2007 10:32:37 +0000
  • Cc: Xen Development Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 23 Mar 2007 03:32:32 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdtNpNI0hsXKtkpEduVTwAX8io7RQ==
  • Thread-topic: [Xen-devel] RFC: [0/2] Remove netloop by lazy copying in netback

On 23/3/07 03:17, "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxx> wrote:

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

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

PS. I've stripped my name from the To/Cc lists! :-)

 -- Keir



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