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] Vanilla Linux and has_foreign_mapping

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Vanilla Linux and has_foreign_mapping
From: Michael Abd-El-Malek <mabdelmalek@xxxxxxx>
Date: Mon, 21 Apr 2008 14:17:04 -0400
Cc: Mark McLoughlin <markmc@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Eduardo Habkost <ehabkost@xxxxxxxxxx>
Delivery-date: Mon, 21 Apr 2008 11:17:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <480CD8AE.5010801@xxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C43292EA.16E1D%keir.fraser@xxxxxxxxxxxxx> <480CD8AE.5010801@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (Windows/20080213)
Michael Abd-El-Malek wrote:
Keir Fraser wrote:
Hi there,

Take a look at changeset 488 in

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?


It's all a bit of a pain I'm afraid. :-(

 -- Keir

On 20/4/08 22:19, "Michael Abd-El-Malek" <mabdelmalek@xxxxxxx> wrote:


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.

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)

/* 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);
+        }
+    }

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;
  } 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: [<c01157f9>] 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:[<c01157f9>] EFLAGS: 00010246 CPU: 0
EIP is at pgd_mop_up_pmds+0x6a/0xd8
Call Trace:
  [<c01158bf>] pgd_free+0x8/0x19
  [<c011fca0>] __mmdrop+0x16/0x2a
  [<c01244bc>] do_exit+0x1b3/0x569
  [<c01248d5>] do_group_exit+0x63/0x7a
  [<c0107066>] syscall_call+0x7/0xb

Has anyone else implemented this functionality in the mainline Linux tree?
Any thoughts?


Xen-devel mailing list

Xen-devel mailing list