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] [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.



Derek Murray.

Xen-devel mailing list