[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
implicit grant unmap hacking [was RE: [Xen-devel] 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).
Is there a "pte update validation" function that I'm not noticing?
Any suggestions much appreciated.
Xen-devel mailing list