Xen devel - Mar 2006 - implicit grant unmap hacking [was RE: Grant tables from dom0 userspace?]

> I''d think it would make more sense to store the PTE
> that the grant has been bound to explicitly
Already did that.
> and hook the implicit unmap off of the pte update
> validation code in Xen. 
I''m investigating your suggestion with a quick experiment.  I put a
hack
into ptwr_do_page_fault(), which is one place where  the pte address is
available.  The hack simply does a prink() when detecting a pte with the
_PAGE_GNTTAB bit set.  I never see the printk() when the OS squashes the
mapping PTE.  Instead, I get the backtrace I already mentioned, namely:

(XEN)    [<ff13603e>] put_page_from_l1e+0xd0/0x1af
(XEN)    [<ff13a891>] revalidate_l1+0x159/0x168
(XEN)    [<ff13aac1>] ptwr_flush+0x221/0x32f
(XEN)    [<ff13b6a7>] cleanup_writable_pagetable+0x5c/0x7d
(XEN)    [<ff137c20>] do_mmuext_op+0x85/0x8c1
(XEN)    [<ff149e0f>] hypercall+0x8f/0xaf

I was hoping that ptwr_do_page_fault() would happen first, but it
doesn''t happen at all.  I conclude that the page table is  writable by
the paravirtual OS, and the hypercall() above is Xen''s first chance to
notice the squashed pte (albeit without the pte addr readily available).
Make sense?

Is there a "pte update validation" function that I''m not
noticing?

Any suggestions much appreciated.

-steve

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel