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.

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

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?


Xen-devel mailing list

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