From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932510AbXBPR1m (ORCPT ); Fri, 16 Feb 2007 12:27:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932566AbXBPR1m (ORCPT ); Fri, 16 Feb 2007 12:27:42 -0500 Received: from gw.goop.org ([64.81.55.164]:43119 "EHLO mail.goop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932510AbXBPR1l (ORCPT ); Fri, 16 Feb 2007 12:27:41 -0500 Message-ID: <45D5E98B.4070904@goop.org> Date: Fri, 16 Feb 2007 09:27:39 -0800 From: Jeremy Fitzhardinge User-Agent: Thunderbird 1.5.0.9 (X11/20070212) MIME-Version: 1.0 To: Keir Fraser CC: Andi Kleen , Zachary Amsden , xen-devel@lists.xensource.com, virtualization@lists.osdl.org, linux-kernel@vger.kernel.org, Jan Beulich , Chris Wright , Ian Pratt , Andrew Morton , Christian Limpach Subject: Re: [Xen-devel] Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Keir Fraser wrote: > On 16/2/07 17:10, "Keir Fraser" wrote: > > >> On 16/2/07 16:46, "Jeremy Fitzhardinge" wrote: >> >> >>> Yes, that would work. Unfortunately that's i386 arch-specific, whereas >>> the rest of this code is generic. I guess I could just move it all to >>> arch/i386/mm. >>> >> This whole thing isn't an issue on ia64 (they no-op lock_vm_area) and >> powerpc doesn't use any of the Xen driver code at this time. >> vmalloc_sync_all is supported by both i386 and x86_64, so we can make the >> call conditional on CONFIG_X86 so that ia64 will continue to build. This is >> what I've done in xen-unstable. >> > > > In fact that file is only built for i386 and x86_64, so there really is no > problem with using vmalloc_sync_all() directly and without ifdef. > I had moved it to mm/vmalloc.c in response to previous review comments (namely, its not Xen specific, so it shouldn't live in the Xen part of the tree). J From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: [patch 12/21] Xen-paravirt: Allocate and free vmalloc areas Date: Fri, 16 Feb 2007 09:27:39 -0800 Message-ID: <45D5E98B.4070904@goop.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: Zachary Amsden , xen-devel@lists.xensource.com, Ian Pratt , virtualization@lists.osdl.org, linux-kernel@vger.kernel.org, Jan Beulich , Chris Wright , Andi Kleen , Andrew Morton , Christian Limpach List-Id: virtualization@lists.linuxfoundation.org Keir Fraser wrote: > On 16/2/07 17:10, "Keir Fraser" wrote: > > >> On 16/2/07 16:46, "Jeremy Fitzhardinge" wrote: >> >> >>> Yes, that would work. Unfortunately that's i386 arch-specific, whereas >>> the rest of this code is generic. I guess I could just move it all to >>> arch/i386/mm. >>> >> This whole thing isn't an issue on ia64 (they no-op lock_vm_area) and >> powerpc doesn't use any of the Xen driver code at this time. >> vmalloc_sync_all is supported by both i386 and x86_64, so we can make the >> call conditional on CONFIG_X86 so that ia64 will continue to build. This is >> what I've done in xen-unstable. >> > > > In fact that file is only built for i386 and x86_64, so there really is no > problem with using vmalloc_sync_all() directly and without ifdef. > I had moved it to mm/vmalloc.c in response to previous review comments (namely, its not Xen specific, so it shouldn't live in the Xen part of the tree). J