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


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

To: Daniel Stodden <daniel.stodden@xxxxxxxxxx>
Subject: [Xen-devel] Re: blktap: Sync with XCP, dropping zero-copy.
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 17 Nov 2010 14:14:58 -0800
Cc: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 17 Nov 2010 14:15:44 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1290031020.11102.1410.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>
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> <4CE41853.1010000@xxxxxxxx> <1290025317.11102.1216.camel@xxxxxxxxxxxxxxxxxxxxxxx> <4CE442EA.1090708@xxxxxxxx> <1290031020.11102.1410.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101027 Fedora/3.1.6-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.6
On 11/17/2010 01:57 PM, Daniel Stodden wrote:
> On Wed, 2010-11-17 at 16:02 -0500, Jeremy Fitzhardinge wrote:
>> On 11/17/2010 12:21 PM, Daniel Stodden wrote:
>>> And, like all granted frames, not owning them implies they are not
>>> resolvable via mfn_to_pfn, thereby failing in follow_page, thereby gup()
>>> without the VM_FOREIGN hack.
>> Hm, I see.  Well, I wonder if using _PAGE_SPECIAL would help (it is put
>> on usermode ptes which don't have a backing struct page).  After all,
>> there's no fundamental reason why it would need a pfn; the mfn in the
>> pte is what's actually needed to ultimately generate a DMA descriptor.
> The kernel needs the page structs at least for locking and refcounting.


> There's also a some trickier stuff in there. Like redirtying disk-backed
> user memory after read completion, in case it's been laundered. (So that
> an AIO on unpinned user memory doesn't subsequently get flashed back
> when cycling through swap, if I understood that thing correctly.)
> Doesn't apply for blktap (it's all reserved pages). All I mean is: I
> wouldn't exactly see some innocent little dio hack or so shape up in
> there.
> Kernel allowing to DMA into a bare pfnmap -- From the platform POV, I'd
> agree. E.g. there's a concept of devices DMA-ing into arbitrary I/O
> memory space, not host memory, on some bus architectures. PCI would come
> to my mind (the old shared medium stuff, unsure about those newfangled
> P-t-P topologies). But not in Linux, so I presently don't see anybody
> upstream bothering to make block-I/O request addressing more forgiving
> than it is.
> PAGE_SPECIAL -- to the kernel, that means the opposite: page structs
> which aren't backed by 'real' memory, so gup(), for example, is told to
> fail (how nasty).

It's pfns with no corresponding struct page - it's the pte level
equivalent of VM_PFNMAP at the VMA level.  But you're right that we
can't do without struct pages.

So we're back to needing a way of mapping from a random mfn to a pfn so
we can find the corresponding struct page.  I would be tempted to put a
layer over m2p to allow local m2p mappings to override the global m2p table.

>  In contrast, VM_FOREIGN is non-memory backed by page
> structs.


Xen-devel mailing list