This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Daniel Stodden <Daniel.Stodden@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: blktap: Sync with XCP, dropping zero-copy.
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Fri, 19 Nov 2010 10:57:30 +0000
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 19 Nov 2010 03:00:16 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1290109065.28752.58.camel@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <1289604707-13378-1-git-send-email-daniel.stodden@xxxxxxxxxx> <4CDDE0DA.2070303@xxxxxxxx> <1289620544.11102.373.camel@xxxxxxxxxxxxxxxxxxxxxxx> <4CE17B80.7080606@xxxxxxxx> <1289898792.23890.214.camel@ramone> <4CE2C5B1.1050806@xxxxxxxx> <1289942932.11102.802.camel@xxxxxxxxxxxxxxxxxxxxxxx> <1290013488.31507.4198.camel@xxxxxxxxxxxxxxxxxxxxxx> <1290022079.11102.1162.camel@xxxxxxxxxxxxxxxxxxxxxxx> <1290088571.31507.5345.camel@xxxxxxxxxxxxxxxxxxxxxx> <1290109065.28752.58.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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...


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>