On 10/07/09 17:15, Steven Smith wrote:
>>>> 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.
>
OK, but that's a fair bit more work.
> 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.
>
Unfortunately the PG_foreign approach is a non-starter for upstream,
mainly because adding new page flags is strongly frowned upon unless
there's a very compelling reason. Unless we can find some other kernel
subsystems which can make use of a page destructor, we probably won't
make the cut. (It doesn't help that there are no more page flags left
on 32-bit.)
The approach I'm trying at the moment is to use the skb destructor
mechanism to grab the pages out of the skb as its freed. To deal with
skb_clone, I'm adding a flag to the skb to force a clone to do a
complete copy so there are no more aliases to the pages (skb_clone
should be rare in the common case).
> 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.
>
Well, if its wrapped by a skb, we can get the skb destructor to handle
the cleanup phase. So long as we get the callback, I don't think it
should affect the rest of the mechanism.
> 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.
>
Block lifetimes are simpler because there's no cloning and bios have a
end_io callback which is more or less equivalent to the skb destructor.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home