From owner-freebsd-mips@FreeBSD.ORG Thu Jan 12 08:47:45 2012 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54FB4106566B; Thu, 12 Jan 2012 08:47:45 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by mx1.freebsd.org (Postfix) with ESMTP id 191E38FC08; Thu, 12 Jan 2012 08:47:44 +0000 (UTC) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 832F3291FE5; Thu, 12 Jan 2012 02:30:43 -0600 (CST) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 72C2F297607; Thu, 12 Jan 2012 02:30:43 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh2.mail.rice.edu, auth channel Received: from mh2.mail.rice.edu ([127.0.0.1]) by mh2.mail.rice.edu (mh2.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id FZWvmp1eL6sH; Thu, 12 Jan 2012 02:30:43 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id EA138291FE5; Thu, 12 Jan 2012 02:30:42 -0600 (CST) Message-ID: <4F0E9A31.5070401@rice.edu> Date: Thu, 12 Jan 2012 02:30:41 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: "Jayachandran C." References: <4F0E1965.6060808@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Oleksandr Tymoshenko , "freebsd-mips@freebsd.org" Subject: Re: MIPS64 modules X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 08:47:45 -0000 On 01/12/2012 01:50, Jayachandran C. wrote: > On Thu, Jan 12, 2012 at 4:51 AM, Oleksandr Tymoshenko wrote: >> Modules on MIPS use the same interface as AMD64 modules: >> sys/kern/link_elf_obj.c. It works for MIPS32 but there is a problem >> with MIPS64. sys/kern/link_elf_obj.c calls vm_map_find that uses >> KERNBASE as a map base. As I told - it works for mips32 because >> KERNBASE for mips32 is located before actual virtual memory area >> (KERNBASE points to directly-mapped KSEG0 segment). But for MIPS64 >> it's not the case - KERNBASE points to the very end of address space >> and vm_map_find fails. >> >> Using VM_MIN_KERNEL_ADDRESS fixes this problem. So the question is - >> what should I do? Add #ifdef to link_elf_obj.c as in kmem_init in >> vm/vm_kern.c or change KERNBASE to VM_MIN_KERNEL_ADDRESS? > This is probably the right fix for both 32 and 64-bit mips. Using a > KSEG0 address as argument for vm_map_find is not correct as the kernel > map does not include that region for mips. > > This reminds me of another issue I had seen in kern/link_elf.c, the > value of linker_kernel_file->address is also set to KERNBASE, but this > really should be KERNLOADADDR (used in our conf files) for mips. I was somewhat surprised to find that KERNBASE points to the direct map. What is the virtual address range for a running kernel's code and data segments? In other words, are the kernel code and data segments accessed through the direct map even after initialization? Alan