Re: [Xen-devel] Re: blktap: Sync with XCP, dropping zero-copy.

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Thu, 2010-11-18 at 19:37 +0000, Daniel Stodden wrote:
> On Thu, 2010-11-18 at 08:56 -0500, Ian Campbell wrote:
> > On Wed, 2010-11-17 at 19:27 +0000, Daniel Stodden wrote:
> > > On Wed, 2010-11-17 at 12:04 -0500, Ian Campbell wrote:
> > > > On Tue, 2010-11-16 at 21:28 +0000, Daniel Stodden wrote:

> > > Instead, there's blkback-pagemap, specifically to map that SG page entry
> > > *back* to the original gref from a table, and *redo* the entire gntmap +
> > > p2m thing another time, privately.
> > 
> > In the userland blkback case do you need to redo the mapping? Isn't the
> > original mapping (including pte update) of the granted mfn into the
> > struct page associated with the user address sufficient?
> 
> It's completely sufficient. Running the sring in tapdisk straight away
> implies mapping once and for all. The present aliasing happens because
> of the two arrows in the following request submission chain: blkback ->
> tapdev -> disk. Each a designating I/O submissing to a blk request
> queue. It's just for the stacking.

Great, just wanted to check I'd understood correctly.

> > Is the reason gup() doesn't work is that it tries to go from a pte_entry
> > to a struct page (via a pfn, e.g. in vm_normal_page) which involves a
> > m2p translation of the pte value, and this is not valid for a foreign
> > page (since the m2p entry is for the remote domain)?
> 
> Exactly. So either it's VM_FOREIGN, or we maybe go for a somewhat
> cleaner solution by teaching mfn_to_pfn new tricks, such as going
> through a private mfn->gntpfn lookup on the m2p failure path. See the
> related thread with Jeremy. I guess you'd have additional thoughts on
> that.

I saw the thread but don't have any particular thoughts, it seems like
an eminently plausible idea...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel