: Make linux smarter about using batched PTE updates

All,
Attached is a patch to make batched PTE updates smarter. Basically, if
you
run a kernel with batched PTE capability on a hypervisor that doesn't support it, you get lots of:

(XEN) mm.c:2453:d2 Invalid page update command 2
(XEN) printk: 333 messages suppressed.
(XEN) mm.c:2453:d2 Invalid page update command 2

on the hypervisor console.

It doesn't seem to be a security problem, since it is rate-limited, but it is an
annoyance. The patch just looks at the return code from the first such hypercall, and if we fail with ENOSYS, we just mark it as "hypervisor_no_batch_update" and never try again. Patch originally from Rik van
Riel.

Signed-off-by Chris Lalancette <[email protected]>

Return-Path: <[email protected]>
Received: from pobox.corp.redhat.com ([unix socket])
by pobox.corp.redhat.com (Cyrus v2.2.12-Invoca-RPM-2.2.12-8.1.RHEL4) with LMTPA;
Tue, 11 Mar 2008 16:31:11 -0400
X-Sieve: CMU Sieve 2.2
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m2BKVBZT029794 for <[email protected]>; Tue, 11 Mar 2008 16:31:11 -0400
Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m2BKV9K4008734 for <[email protected]>; Tue, 11 Mar 2008 16:31:09 -0400
Received: from cuia.boston.redhat.com (cuia.boston.redhat.com [172.16.80.109]) by mail.boston.redhat.com (8.13.1/8.13.1) with ESMTP id m2BKV94q020893 for <[email protected]>; Tue, 11 Mar 2008 16:31:09 -0400
Date: Tue, 11 Mar 2008 16:31:08 -0400
From: Rik van Riel <[email protected]>
To: [email protected]
Subject: quiet down xen mprotect printks
Message-ID: <[email protected]>
Organization: Red Hat, Inc
X-Mailer: Claws Mail 3.1.0 (GTK+ 2.12.1; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254

It doesn't get much simpler than this :)

Please double-check the bit in mm/mmap.c to make sure I did this the right way around.

--- linux-2.6.18.noarch/arch/i386/mm/hypervisor.c.printk 2008-03-11 18:12:34.000000000 -0400
+++ linux-2.6.18.noarch/arch/i386/mm/hypervisor.c 2008-03-11 18:16:38.000000000 -0400

arch/i386/mm/hypervisor.c renamed from arch/i386/mm/hypervisor.c.printk +7 -0

@@ -458,6 +458,7 @@
 #endif
 
 #define MAX_BATCHED_FULL_PTES 32
+static int hypervisor_no_batch_update;
 
 int xen_change_pte_range(struct mm_struct *mm, pmd_t *pmd,
 unsigned long addr, unsigned long end, pgprot_t newprot)

@@ -467,6 +468,9 @@
 pte_t *pte;
 spinlock_t *ptl;
 
+ if (hypervisor_no_batch_update)
+  return 0;
+
 pte = pte_offset_map_lock(mm, pmd, addr, &ptl);
 do {
 if (pte_present(*pte)) {

@@ -484,5 +488,8 @@
 rc = HYPERVISOR_mmu_update( &u[0], i, NULL, DOMID_SELF);
 pte_unmap_unlock(pte - 1, ptl);
 BUG_ON(rc && rc != -ENOSYS);
+ /* Don't try again. This hypervisor does not support batch updates. */
+ if (rc == -ENOSYS)
+  hypervisor_no_batch_update = 1;
 return !rc;
 }

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

We expose feature flag XENFEAT_mmu_pt_update_preserve_ad for this purpose, which means you do not need to attempt the hypercall even once. See
http://xenbits.xensource.com/linux-2.6.18-xen.hg for example usage, in the very file and function you patch below.