> >> Thanks. I've pulled it anyway, but not yet merged it into anything yet.
> >>
> > Okay. I'm going to change the interface a bit following the review
> > comments; would you prefer I shove a fixup patch on the end or edit
> > history and keep the patches sensibly self-contained?
> At this point I haven't done anything with the branch, so just rewrite
> it to your heart's content.
Okay.
> BTW, do you see this is something as a candidate for merging upstream?
I've mostly been defining ``upstream'' as you, but, yes, sending it
further would be good.
> > I needed to make some changes to netback to make forwarding packets
> > between NC1 and NC2 interfaces work, but apart from that it's fairly
> > self-contained. Would you like me to rebase to
> > xen/dom0/backend/netback?
> An outstanding problem with netback is how we can deal with "foreign"
> pages in dom0's network stack. The current approach isn't viable for
> upstream, but there has only been slow movement in coming up with a
> better approach.
>
> I haven't looked at nc2 yet, but does it use the same technique for
> memory management, or something else?
The NC2 approach is basically similar to the NC1 approach, but
generalised so that NC1 and NC2 can cooperate in a reasonably sane
way. It still uses the PG_foreign bit to identify foreign pages, and
the page->private and page->mapping fields for various bits of
information.
The basic idea is that everything which can map foreign pages and
expose them to the rest of Linux needs to allocate a foreign page
tracker (effectively an array of (domid, grant_ref, void *ctxt)
tuples), and to register mapped pages with that tracker. It then uses
the top few bits of page->private to identify the tracker, and the
rest to index into the array. This allows you to forward packets from
a foreign domain without knowing whether it was received by NC1 or
NC2.
Arguably, blkback should be using this mechanism as well, but since
we've gotten away with it so far I thought it'd be best to let
sleeping dogs lie. The only time it'd make any difference would be
when pages out of a block request somehow get attached to network
packets, which seems unlikely.
Steven.
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home