Xen devel - Mar 2008 - [PATCH]: 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 <clalance@redhat.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
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.

 -- Keir

On 11/3/08 21:07, "Chris Lalancette" <clalance@redhat.com>
wrote:
> 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 <clalance@redhat.com>
> Return-Path: <riel@redhat.com>
> 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 <clalance@pobox.corp.redhat.com>; 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 <clalance@int-mx1.corp.redhat.com>; 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 <clalance@redhat.com>; Tue, 11 Mar 2008 16:31:09 -0400
> Date: Tue, 11 Mar 2008 16:31:08 -0400
> From: Rik van Riel <riel@redhat.com>
> To: clalance@redhat.com
> Subject: quiet down xen mprotect printks
> Message-ID: <20080311163108.0d6ae553@cuia.boston.redhat.com>
> 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
> @@ -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
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser wrote:
> 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.
> 
D''oh.  Should have looked at that tree more closely first....we
didn''t have it
in our tree, but now I see it there.  Thanks for the heads up.

Chris Lalancette

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel