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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2010-11-16 at 21:28 +0000, Daniel Stodden wrote:
> 
> > > Also, I was absolutely certain I once saw VM_FOREIGN support in
> gntdev..
> > > Can't find it now, what happened? Without, there's presently still
> no
> > > zero-copy.
> > 
> > gntdev doesn't need VM_FOREIGN any more - it uses the (relatively
> > new-ish) mmu notifier infrastructure which is intended to allow a
> device
> > to sync an external MMU with usermode mappings.  We're not using it
> in
> > precisely that way, but it allows us to wrangle grant mappings
> before
> > the generic code tries to do normal pte ops on them.
> 
> The mmu notifiers were for safe teardown only. They are not sufficient
> for DIO, which wants gup() to work. If you want zcopy on gntdev, we'll
> need to back those VMAs with page structs.  Or bounce again (gulp,
> just mentioning it). As with the blktap2 patches, note there is no
> difference in the dom0 memory bill, it takes page frames.

I though the VM_FOREIGN stuff which blktap[12] hooks into gup() was
there in order to avoid some deadlock arising from having a single
struct page taking part in nested block I/O. i.e. one I/O created by
blkback and the second from the tapdisk process deadlock against each
other.

I though that in order to work around this blktap creates a second range
of struct pages (the struct vm_foreign_map array in
vma->vm_private_data) which aliases the pages under I/O and then it
hooks gup() to do the switcheroo when necessary.

If the blkback interface is running in userspace (whether in a tapdisk
or qemu process) then there is no nesting of I/O and the only I/O is
from process context and therefore this particular issue is no longer a
problem because we can use a properly struct page backed page without
needing a magic VM_FOREIGN shadow of it?

Have I misunderstood something about the reason for VM_FOREIGN?

Ian.



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