I'm having a couple of problems dealing with pages in dom0 that have
been mapped via a grant from domU, and wondered if anyone can confirm my
suspicions and suggest a way round this.
I pass a grant from domU to dom0, and map it in to dom0 using
xenbus_map_ring_valloc(). This gives me a "struct vm_struct" which
isn't terribly useful as most of it isn't filled out, but it does have a
virtual address for the page in dom0. I need to pass this page to a PCI
device, and so would like to use something like pci_map_single() (or
dma_map_page()) to convert this virtual address into a bus address.
However, neither of these seem to be working as one might hope: they
always return the same value regardless of the address you pass in (at
least for the valid addresses that I've tried).
Subsequent investigations using, for example, follow_page() yield the
same result. Interestingly, to get from the virtual address in dom0 to
a "struct vm_area_struct" that can be used for follow_page() I used
find_vma(). It however claimed that it couldn't find a vma for that
address.
The call to alloc_vm_area() in xenbus_map_ring_valloc() does a walk of
the page tables (using apply_to_page_range()) to, I assume, set things
up appropriately for this new page, and does seem to end up with a valid
"struct page" in its hands. However, I now suspect that it and the
hyperop that maps in the grant are doing something clever, such as only
updating the real page tables in the hypervisor, and doing just enough
to the page tables in dom0 to ensure that things don't go horribly
wrong. Is this correct? If so, when I try and walk the page tables
(using something like follow_page()) in dom0 to get from the virtual
address to a struct page, I find the hacked up entry rather than
something that is useful, and this would explain the above behaviour of
find_vma().
If this is right, any suggestions for how to get from a virtual address
of a page that has been mapped using a grant from domU->dom0, to an
address that is suitable for passing to a PCI device?
Thanks
Kieran
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|