| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
Re: [Xen-devel] [PATCH 0/3] [RFC] User-space grant table device
On 21 Mar 2007, at 04:32, Isaku Yamahata wrote:
This patch doesn't work on ia64 and ppc because they doesn't support
GNTMAP_application_map which is x86 speicific. The flag doesn't make
sense for ia64 and ppc. (When auto_translated_physmap_mode is enabled,
GNTMAP_application_map isn't necessary.)
Fortunately there was the similar issue in blktap. It was solved
by utilizing auto_translated_physmap_mode.
Please forgive my ignorance of ia64 and ppc, as I don't have ready
access to either for development. I based my work on the blktap
driver, although there were some bits that I didn't understand.
blktap appears to map each grant into kernel space and, when not
using auto-translated mode, into user space as well. If it is using
auto-translated mode, then the grant is only mapped into the kernel.
Am I correct in thinking that the use of the VM_FOREIGN flag, plus
the use of vm_private_data to store an array of struct page pointers,
enables the pages to be mapped into user space using get_user_pages()
(which is called by make_pages_present(), which is called by
do_mmap_pgoff())? Or is it the call to vm_insert_page()?
If it is diffucult for you to work on it (ia64 or ppc machine is
necessary),
I'd like to do.
I'll have a try at adding the code to work in these cases, though I
would appreciate your feedback on whether the changes are correct.
Your goal seems to be to rewrite xen console daemon and xensotred.
(and blktap if possible).
They are very fundamental, so I want to resolve it in advance
instead of finding/fixing the breakage after the commit.
Definitely!
Regards,
Derek Murray.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home