Hello All, I''m contemplating ways to avoid the domain_crash() in mm.c line ~615 without requiring new OS hooks. This crash occurs when the operating system writes a zero to the PTE for a grant mapping without an explicit Xen call to unmap. In hacking around, it seems the problem is this: When the mapping PTE gets squashed, Xen''s cleanup_writable_pagetable() has no way to find the correct maptrack entry for the affected mapping. Consequently, the grant mapping is not properly cleaned-up. Sound correct? Are there worse problems here? Thanks, -steve _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 14 Feb 2006, at 21:07, King, Steven R wrote:> I''m contemplating ways to avoid the domain_crash() in mm.c line ~615 > without requiring new OS hooks. This crash occurs when the operating > system writes a zero to the PTE for a grant mapping without an explicit > Xen call to unmap. > > In hacking around, it seems the problem is this: When the mapping PTE > gets squashed, Xen''s cleanup_writable_pagetable() has no way to find > the > correct maptrack entry for the affected mapping. Consequently, the > grant mapping is not properly cleaned-up. > > Sound correct? Are there worse problems here?That''s right. That grant will hang around until the domain is destroyed, at which point the grant is cleaned up by gnttab_release_mappings(). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Maybe Matching Threads
- implicit grant unmap hacking [was RE: Grant tables from dom0 userspace?]
- xenwatch: page allocation failure: order:4, mode:0x10c0d0 xen_netback:xenvif_alloc: Could not allocate netdev for vif16.0
- [Doc] writeup for error handling usage in XEN
- RFC: [0/2] Remove netloop by lazy copying in netback
- netfront.c: gnttab_query_foreign_access returns non zero in network_tx_buf_gc