From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 22 Feb 2013 17:57:46 +0100 (CET) Received: from aserp1040.oracle.com ([141.146.126.69]:36373 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S6827565Ab3BVQ5phCrFS (ORCPT ); Fri, 22 Feb 2013 17:57:45 +0100 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1MGteJ5029018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Feb 2013 16:55:41 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1MGtb0U026898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2013 16:55:38 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1MGtaWE031325; Fri, 22 Feb 2013 10:55:36 -0600 Received: from phenom.dumpdata.com (/50.195.21.189) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 22 Feb 2013 08:55:35 -0800 Received: by phenom.dumpdata.com (Postfix, from userid 1000) id 2B90E1C3935; Fri, 22 Feb 2013 11:55:31 -0500 (EST) Date: Fri, 22 Feb 2013 11:55:31 -0500 From: Konrad Rzeszutek Wilk To: "H. Peter Anvin" Cc: Linus Torvalds , "David S. Miller" , "H. Peter Anvin" , "Rafael J. Wysocki" , stable@vger.kernel.org, Alexander Duyck , Andrea Arcangeli , Andrew Morton , Andrzej Pietrasiewicz , Arnd Bergmann , Borislav Petkov , Borislav Petkov , Christoph Lameter , Daniel J Blueman , Dave Hansen , Eric Biederman , Fenghua Yu , Frederic Weisbecker , Gleb Natapov , Gokul Caushik , "H. J. Lu" , Hugh Dickins , Ingo Molnar , Ingo Molnar , Jacob Shin , Jamie Lokier , Jarkko Sakkinen , Jeremy Fitzhardinge , Joe Millenbach , Joerg Roedel , Johannes Weiner , Josh Triplett , Kyungmin Park , Lee Schermerhorn , Len Brown , Linux Kernel Mailing List , Marcelo Tosatti , Marek Szyprowski , Matt Fleming , Mel Gorman , Paul Turner , Pavel Machek , Pekka Enberg , Peter Zijlstra , Ralf Baechle , Rik van Riel , Rob Landley , Russell King , Rusty Russell , Shuah Khan , Shuah Khan , Stefano Stabellini , Steven Rostedt , Thomas Gleixner , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Yasuaki Ishimatsu , Yinghai Lu , Zachary Amsden , avi@redhat.com, linux-mips@linux-mips.org, linux-pm@vger.kernel.org, mst@redhat.com, sparclinux@vger.kernel.org, virtualization@lists.linux-foundation.org, xen-devel@lists.xensource.com Subject: Re: [GIT PULL] x86/mm changes for v3.9-rc1 Message-ID: <20130222165531.GA29308@phenom.dumpdata.com> References: <201302220034.r1M0Y6O8008311@terminus.zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201302220034.r1M0Y6O8008311@terminus.zytor.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-archive-position: 35807 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: konrad.wilk@oracle.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips Return-Path: On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote: > Hi Linus, > > This is a huge set of several partly interrelated (and concurrently > developed) changes, which is why the branch history is messier than > one would like. > > The *really* big items are two humonguous patchsets mostly developed > by Yinghai Lu at my request, which completely revamps the way we > create initial page tables. In particular, rather than estimating how > much memory we will need for page tables and then build them into that > memory -- a calculation that has shown to be incredibly fragile -- we > now build them (on 64 bits) with the aid of a "pseudo-linear mode" -- > a #PF handler which creates temporary page tables on demand. > > This has several advantages: > > 1. It makes it much easier to support things that need access to > data very early (a followon patchset uses this to load microcode > way early in the kernel startup). > > 2. It allows the kernel and all the kernel data objects to be invoked > from above the 4 GB limit. This allows kdump to work on very large > systems. > > 3. It greatly reduces the difference between Xen and native (Xen's > equivalent of the #PF handler are the temporary page tables created > by the domain builder), eliminating a bunch of fragile hooks. > > The patch series also gets us a bit closer to W^X. > > Additional work in this pull is the 64-bit get_user() work which you > were also involved with, and a bunch of cleanups/speedups to > __phys_addr()/__pa(). Looking at figuring out which of the patches in the branch did this, but with this merge I am getting a crash with a very simple PV guest (booted with one 1G): Call Trace: [] xen_get_user_pgd+0x5a <-- [] xen_get_user_pgd+0x5a [] xen_write_cr3+0x77 [] init_mem_mapping+0x1f9 [] setup_arch+0x742 [] printk+0x48 [] start_kernel+0x90 [] __add_preferred_console.clone.1+0x9b [] x86_64_start_reservations+0x2a [] xen_start_kernel+0x564 And the hypervisor says: (XEN) d7:v0: unhandled page fault (ec=0000) (XEN) Pagetable walk from ffffea000005b2d0: (XEN) L4[0x1d4] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S (XEN) Domain 7 (vcpu#0) crashed on cpu#3: (XEN) ----[ Xen-4.2.0 x86_64 debug=n Not tainted ]---- (XEN) CPU: 3 (XEN) RIP: e033:[] (XEN) RFLAGS: 0000000000000206 EM: 1 CONTEXT: pv guest (XEN) rax: ffffea0000000000 rbx: 0000000001a0c000 rcx: 0000000080000000 (XEN) rdx: 000000000005b2a0 rsi: 0000000001a0c000 rdi: 0000000000000000 (XEN) rbp: ffffffff81a01dd8 rsp: ffffffff81a01d90 r8: 0000000000000000 (XEN) r9: 0000000010000001 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000001000000000 r14: 0000000000000000 (XEN) r15: 0000000000100000 cr0: 000000008005003b cr4: 00000000000406f0 (XEN) cr3: 0000000411165000 cr2: ffffea000005b2d0 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=ffffffff81a01d90: (XEN) 0000000080000000 0000000000000000 0000000000000000 ffffffff8103feba (XEN) 000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b What is bizzare is that I do recall testing this (and Stefano also did it). So I am not sure what has altered. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [GIT PULL] x86/mm changes for v3.9-rc1 Date: Fri, 22 Feb 2013 11:55:31 -0500 Message-ID: <20130222165531.GA29308@phenom.dumpdata.com> References: <201302220034.r1M0Y6O8008311@terminus.zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <201302220034.r1M0Y6O8008311@terminus.zytor.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: "H. Peter Anvin" Cc: linux-mips@linux-mips.org, Jeremy Fitzhardinge , "H. J. Lu" , Frederic Weisbecker , Joe Millenbach , virtualization@lists.linux-foundation.org, Gokul Caushik , Ralf Baechle , Pavel Machek , "H. Peter Anvin" , sparclinux@vger.kernel.org, Christoph Lameter , Ingo Molnar , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Marek Szyprowski , Andrea Arcangeli , Lee Schermerhorn , xen-devel@lists.xensource.com, Russell King , Len Brown , Joerg Roedel , linux-pm@vger.kernel.org, Hugh Dickins , Yasuaki Ishimatsu List-Id: linux-pm@vger.kernel.org On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote: > Hi Linus, > > This is a huge set of several partly interrelated (and concurrently > developed) changes, which is why the branch history is messier than > one would like. > > The *really* big items are two humonguous patchsets mostly developed > by Yinghai Lu at my request, which completely revamps the way we > create initial page tables. In particular, rather than estimating how > much memory we will need for page tables and then build them into that > memory -- a calculation that has shown to be incredibly fragile -- we > now build them (on 64 bits) with the aid of a "pseudo-linear mode" -- > a #PF handler which creates temporary page tables on demand. > > This has several advantages: > > 1. It makes it much easier to support things that need access to > data very early (a followon patchset uses this to load microcode > way early in the kernel startup). > > 2. It allows the kernel and all the kernel data objects to be invoked > from above the 4 GB limit. This allows kdump to work on very large > systems. > > 3. It greatly reduces the difference between Xen and native (Xen's > equivalent of the #PF handler are the temporary page tables created > by the domain builder), eliminating a bunch of fragile hooks. > > The patch series also gets us a bit closer to W^X. > > Additional work in this pull is the 64-bit get_user() work which you > were also involved with, and a bunch of cleanups/speedups to > __phys_addr()/__pa(). Looking at figuring out which of the patches in the branch did this, but with this merge I am getting a crash with a very simple PV guest (booted with one 1G): Call Trace: [] xen_get_user_pgd+0x5a <-- [] xen_get_user_pgd+0x5a [] xen_write_cr3+0x77 [] init_mem_mapping+0x1f9 [] setup_arch+0x742 [] printk+0x48 [] start_kernel+0x90 [] __add_preferred_console.clone.1+0x9b [] x86_64_start_reservations+0x2a [] xen_start_kernel+0x564 And the hypervisor says: (XEN) d7:v0: unhandled page fault (ec=0000) (XEN) Pagetable walk from ffffea000005b2d0: (XEN) L4[0x1d4] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S (XEN) Domain 7 (vcpu#0) crashed on cpu#3: (XEN) ----[ Xen-4.2.0 x86_64 debug=n Not tainted ]---- (XEN) CPU: 3 (XEN) RIP: e033:[] (XEN) RFLAGS: 0000000000000206 EM: 1 CONTEXT: pv guest (XEN) rax: ffffea0000000000 rbx: 0000000001a0c000 rcx: 0000000080000000 (XEN) rdx: 000000000005b2a0 rsi: 0000000001a0c000 rdi: 0000000000000000 (XEN) rbp: ffffffff81a01dd8 rsp: ffffffff81a01d90 r8: 0000000000000000 (XEN) r9: 0000000010000001 r10: 0000000000000000 r11: 0000000000000000 (XEN) r12: 0000000000000000 r13: 0000001000000000 r14: 0000000000000000 (XEN) r15: 0000000000100000 cr0: 000000008005003b cr4: 00000000000406f0 (XEN) cr3: 0000000411165000 cr2: ffffea000005b2d0 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033 (XEN) Guest stack trace from rsp=ffffffff81a01d90: (XEN) 0000000080000000 0000000000000000 0000000000000000 ffffffff8103feba (XEN) 000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b What is bizzare is that I do recall testing this (and Stefano also did it). So I am not sure what has altered.