From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Abd-El-Malek Subject: Re: Vanilla Linux and has_foreign_mapping Date: Mon, 21 Apr 2008 14:17:04 -0400 Message-ID: <480CDA20.6080109@cmu.edu> References: <480CD8AE.5010801@cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <480CD8AE.5010801@cmu.edu> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Mark McLoughlin , Jeremy Fitzhardinge , xen-devel , Eduardo Habkost List-Id: xen-devel@lists.xenproject.org Michael Abd-El-Malek wrote: > Keir Fraser wrote: >> Hi there, >> >> Take a look at changeset 488 in >> http://xenbits.xensource.com/linux-2.6.18-xen.hg >> >> There you will see that we now have a new page flag (_PAGE_IO) that we >> apply >> to any PTE which maps I/O pages or 'foreign' pages. We use this to avoid >> pseudophysical<->machine translations when getting/setting ptes, because >> such translations are not generally valid for such pages, but equally >> it may >> obviate the need for the has_foreign_mappings flag. This is because we >> can >> now have pte_pfn() return an invalid pfn for foreign mappings based on >> the >> _PAGE_IO flag in the pte, rather than by the roundabout logic >> implemented in >> pfn_to_local_mfn(). The latter relies on us keeping the pagetables >> pinned -- >> so if we no longer rely on it then we no longer need to forcibly keep >> things >> pinned via the has_foreign_mappings flag. >> >> Unfortunately I had to keep the has_foreign_mappings flag for other >> reasons >> in the 2.6.18 tree: gntdev and blktap device drivers use it to >> forcibly keep >> ptes pinned which contain grant mappings. This could probably be fixed >> within those drivers by having them pin just the pte pages that contain >> grant mappings. Then even on early-unpin (which has foreign_mappings >> currently defeats) we would still have the necessary pte-containing pages >> pinned even though the pgd-containin g page gets unpinned. > > Yeah I'm in a similar situation as gntdev and blktap. > > So on 2.6.25, which doesn't have has_foreign_mappings, you're suggesting > that I pin the pte pages that contain grant mappings. How do I > accomplish that? And on process exit, do I have to take any extra steps > to unpin the pte page, or will those pages be freed regardless of their > "pin status"? OK I took a quick look at the code. On 2.6.25, xen_exit_mmap calls xen_pgd_unpin. xen_pgd_unpin walks over a pgd and calls unpin_page on any pinned pages. So it seems the current pgd_unpin code will not let us have any pte pages unpinned? > Thanks, > Mike > >> It's all a bit of a pain I'm afraid. :-( >> >> -- Keir >> >> On 20/4/08 22:19, "Michael Abd-El-Malek" wrote: >> >>> Hello, >>> >>> I'm trying to add support to Linux 2.6.25 for the >>> "has_foreign_mappings" MMU >>> context flag. Xen's Linux 2.6.18 tree uses this flag, so that page >>> tables are >>> properly disposed of when an application exits when it has foreign >>> mappings. >>> See: >>> http://lists.xensource.com/archives/html/xen-devel/2006-08/msg00038.html >>> >>> Here is my attempt: >>> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c >>> index 2a054ef..3e51897 100644 >>> --- a/arch/x86/xen/mmu.c >>> +++ b/arch/x86/xen/mmu.c >>> @@ -633,8 +633,13 @@ void xen_exit_mmap(struct mm_struct *mm) >>> spin_lock(&mm->page_table_lock); >>> >>> /* pgd may not be pinned in the error exit path of execve */ >>> - if (PagePinned(virt_to_page(mm->pgd))) >>> - xen_pgd_unpin(mm->pgd); >>> + if (PagePinned(virt_to_page(mm->pgd))) { >>> + if (mm->context.has_foreign_mappings) { >>> + printk("%s: because of has_foreign_mappings, delaying >>> unpinning\n", __FUNCTION__); >>> + } else { >>> + xen_pgd_unpin(mm->pgd); >>> + } >>> + } >>> >>> spin_unlock(&mm->page_table_lock); >>> } >>> diff --git a/include/asm-x86/mmu.h b/include/asm-x86/mmu.h >>> index efa962c..7194698 100644 >>> --- a/include/asm-x86/mmu.h >>> +++ b/include/asm-x86/mmu.h >>> @@ -18,6 +18,9 @@ typedef struct { >>> int size; >>> struct mutex lock; >>> void *vdso; >>> +#ifdef CONFIG_XEN >>> + int has_foreign_mappings; >>> +#endif >>> } mm_context_t; >>> >>> #ifdef CONFIG_SMP >>> >>> Unfortunately, I got the following kernel crash on process exit: >>> >>> BUG: unable to handle kernel paging request at ebdae008 >>> IP: [] pgd_mop_up_pmds+0x6a/0xd8 >>> *pdpt = 000000007f494027 >>> Oops: 0003 [#1] PREEMPT SMP >>> Modules linked in: efsvm(F) nfs lockd sunrpc dm_snapshot dm_mirror >>> dm_mod >>> >>> Pid: 5565, comm: a.out Tainted: GF (2.6.25 #9) >>> EIP: 0061:[] EFLAGS: 00010246 CPU: 0 >>> EIP is at pgd_mop_up_pmds+0x6a/0xd8 >>> ... >>> Call Trace: >>> [] pgd_free+0x8/0x19 >>> [] __mmdrop+0x16/0x2a >>> [] do_exit+0x1b3/0x569 >>> [] do_group_exit+0x63/0x7a >>> [] syscall_call+0x7/0xb >>> >>> Has anyone else implemented this functionality in the mainline Linux >>> tree? >>> Any thoughts? >>> >>> Thanks, >>> Mike > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel