On Jan 31, 2008 2:57 PM, Michael Abd-El-Malek <mabdelmalek@xxxxxxx> wrote:
> I tried to do that by first getting a grant for the user-space memory
> in the source domain as follows:
> page_start = user_buf;
> buffer_mfn = virt_to_mfn(page_start);
> gnttab_grant_foreign_access_ref(grant_ref, info->dev->otherend_id,
> buffer_mfn, 0);
> But the virt_to_mfn call asserted, in include/asm-x86_64/mach-xen/asm/
> The assertion that failed was: BUG_ON(end_pfn && pfn >= end_pfn);
You have another problem here, because virt_to_mfn (and virt_to_page
etc.) operate on kernel virtual addresses, where converting to a
physical address effectively just involves subtracting an offset. User
virtual addresses are handled differently, and you'll have to walk the
page table to find the PTE and from that obtain an MFN.
To respond to Daniel's point, from my reading of the code, the grant
table entry takes a "GMFN", which is equivalent to an MFN on PV guests
without shadow translation. Therefore it shouldn't be necessary to
translate this to a pseudo-physical frame number.
> So a few questions:
> 1) is it even possible to map a domain's user-space page into another
I don't see any problem in principle, though you'll have to make sure
that the page is locked in memory.
> 3) does the blktap driver do something similar? I tried looking at the
> blktap driver, because it looked like it might help. But I'm new to
> the Xen memory management code so it was a bit difficult to follow.
blktap maps memory that was granted by another domain's kernel (in the
blkfront driver) into user-space. Therefore, on the destination side,
this is probably more complicated than you need. However, if you did
want to map the grant into user-space, you could use gntdev, which
employs the same mechanism as blktap.
Xen-devel mailing list