From owner-freebsd-mips@FreeBSD.ORG Thu Jan 12 10:28:17 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 29D2F1065670; Thu, 12 Jan 2012 10:28:17 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id BC3F88FC13; Thu, 12 Jan 2012 10:28:16 +0000 (UTC) Received: by vcbfk1 with SMTP id fk1so2035654vcb.13 for ; Thu, 12 Jan 2012 02:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3VBc07NL0wKaW+oKjUjbs9DejCmdh0XzzAOYVZTNpfw=; b=xEbbGyaH0EbcIbBbOF0PURMnXCqsW4CQEOqNyPhP48L0MPq7Pl3RQiDxAqwIhDts97 9v+cBRO/UlOH7AisP/nJwojGalczk5wfXSDb7nldXV3aO++5ZbBz67Zm55/dlH5uC/Rq yvE6a+o5ddtU6nUD50sq6Nqylbl8obpGN+R1w= MIME-Version: 1.0 Received: by 10.220.155.5 with SMTP id q5mr1770215vcw.4.1326364096095; Thu, 12 Jan 2012 02:28:16 -0800 (PST) Received: by 10.52.88.83 with HTTP; Thu, 12 Jan 2012 02:28:16 -0800 (PST) In-Reply-To: <4F0E9A31.5070401@rice.edu> References: <4F0E1965.6060808@freebsd.org> <4F0E9A31.5070401@rice.edu> Date: Thu, 12 Jan 2012 15:58:16 +0530 Message-ID: From: "Jayachandran C." To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 10:28:17 -0000 On Thu, Jan 12, 2012 at 2:00 PM, Alan Cox wrote: > On 01/12/2012 01:50, Jayachandran C. wrote: >> >> On Thu, Jan 12, 2012 at 4:51 AM, Oleksandr Tymoshenko >> =A0wrote: >>> >>> =A0 =A0Modules 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. > =A0What is the virtual address range for a running kernel's code and data > segments? =A0In other words, are the kernel code and data segments access= ed > through the direct map even after initialization? Yes, this direct map (KSEG0 in 32bit and CKSEG0 in 64bit) maps the first 512MB physical memory and is outside the VM_MIN_KERNEL_ADDRESS - VM_MAX_KERNEL_ADDRESS range. KERNBASE points to the start of this direct map. In 64 bit, there are a few more direct maps (XKPHYS) which maps the whole physical memory (location depends on the caching needed). We use this when we need a direct mapped pointer (by MIPS_PHYS_TO_DIRECT) in 64 bit. This is also outside the kernel min and max vm. JC.