From owner-freebsd-mips@FreeBSD.ORG Tue Jun 1 01:01:32 2010 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 13ACE106567A for ; Tue, 1 Jun 2010 01:01:32 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C51018FC15 for ; Tue, 1 Jun 2010 01:01:31 +0000 (UTC) Received: by vws10 with SMTP id 10so2312792vws.13 for ; Mon, 31 May 2010 18:01:30 -0700 (PDT) Received: by 10.220.123.95 with SMTP id o31mr3933841vcr.163.1275354089178; Mon, 31 May 2010 18:01:29 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.220.199.70 with HTTP; Mon, 31 May 2010 18:01:09 -0700 (PDT) From: Juli Mallett Date: Mon, 31 May 2010 18:01:09 -0700 X-Google-Sender-Auth: -x4nh-PebMreo4VVq--IwCWFOYs Message-ID: To: freebsd-mips@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: HEADS UP: Toolchain changes coming soon. (Octeon, n32, n64) 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: Tue, 01 Jun 2010 01:01:32 -0000 Over the next day or two I am planning to merge changes to GCC and binutils adding support for Octeon and the n32 and n64 ABIs, as well as fixing a couple of bugs in our GCC spec. Note that the Octeon-related patches are necessary to support the Cavium Octeon Simple Executive, which I am planning to import after these changes have been committed, which will be terribly helpful for the Octeon port, in particular a new network driver and hopefully soon crypto and PCI support. If you have any questions or comments please get in touch with me. The contents of the patch may shift some before commit as I do testing on a wider variety of platforms. The full patch to GCC and binutils is at this URL, and I have reproduced the description below: http://people.freebsd.org/~jmallett/mips-toolchain.diff o) Add TARGET_ABI to the MIPS toolchain build process. This sets the default ABI to one of o32, n32 or n64. If it is not set, o32 is assumed as that is the current default. o) Set the default GCC cpu type to any specified TARGET_CPUTYPE. This is necessary to have a working "cc" if e.g. mips64 is specified, as binutils will refuse to link objects using different ISAs in some cases. o) Add support for n32 and n64 ABIs to binutils and GCC. o) Add additional required libgcc2 stubs for n32 and n64. o) Add support for the "mips64r2" architecture to GCC. Add the "octeon" o) When static linking, wrap default libraries in --start-group and --end-group. This is required for static linking to work on n64 with the interdependencies between libraries there. This is what other OSes that support n64 seem to do, as well. o) Fix our GCC spec to define __mips64 for 64-bit targets, not __mips64__, the former being what libgcc, etc., check and the latter seemingly being a misspelling of a hand merge from a Linux spec. o) When no TARGET_CPUTYPE is specified at build time, make GCC take the default ISA from the ABI. Our old defaults were too liberal and assumed that 64-bit ABIs should default to the MIPS64 ISA and that 32-bit ABIs should default to the MIPS32 ISA, when we are supporting or will support some systems based on earlier 32-bit and 64-bit ISAs, most notably MIPS-III. o) Merge a new opcode file (and support code) from a later version of binutils and add flags and code necessary to support Octeon-specific instructions. This should also make merging opcodes for other modern architectures easier. Thanks, Juli. From owner-freebsd-mips@FreeBSD.ORG Tue Jun 1 02:26:38 2010 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 A940D1065678; Tue, 1 Jun 2010 02:26:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBEA8FC17; Tue, 1 Jun 2010 02:26:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o512IInn018102; Mon, 31 May 2010 20:18:19 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 31 May 2010 20:18:27 -0600 (MDT) Message-Id: <20100531.201827.56628267929938337.imp@bsdimp.com> To: jmallett@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-mips@FreeBSD.org Subject: Re: HEADS UP: Toolchain changes coming soon. (Octeon, n32, n64) 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: Tue, 01 Jun 2010 02:26:38 -0000 In message: Juli Mallett writes: : Over the next day or two I am planning to merge changes to GCC and : binutils adding support for Octeon and the n32 and n64 ABIs, as well : as fixing a couple of bugs in our GCC spec. Note that the : Octeon-related patches are necessary to support the Cavium Octeon : Simple Executive, which I am planning to import after these changes : have been committed, which will be terribly helpful for the Octeon : port, in particular a new network driver and hopefully soon crypto and : PCI support. : : If you have any questions or comments please get in touch with me. : The contents of the patch may shift some before commit as I do testing : on a wider variety of platforms. : : The full patch to GCC and binutils is at this URL, and I have : reproduced the description below: : : http://people.freebsd.org/~jmallett/mips-toolchain.diff : : o) Add TARGET_ABI to the MIPS toolchain build process. This sets the : default ABI to one of o32, n32 or n64. If it is not set, o32 is : assumed as that is the current default. : o) Set the default GCC cpu type to any specified TARGET_CPUTYPE. This : is necessary to have a working "cc" if e.g. mips64 is specified, as : binutils will refuse to link objects using different ISAs in some : cases. : o) Add support for n32 and n64 ABIs to binutils and GCC. : o) Add additional required libgcc2 stubs for n32 and n64. : o) Add support for the "mips64r2" architecture to GCC. Add the "octeon" : o) When static linking, wrap default libraries in --start-group and : --end-group. This is required for static linking to work on n64 with : the interdependencies between libraries there. This is what other : OSes that support n64 seem to do, as well. : o) Fix our GCC spec to define __mips64 for 64-bit targets, not : __mips64__, the former being what libgcc, etc., check and the latter : seemingly being a misspelling of a hand merge from a Linux spec. : o) When no TARGET_CPUTYPE is specified at build time, make GCC take : the default ISA from the ABI. Our old defaults were too liberal and : assumed that 64-bit ABIs should default to the MIPS64 ISA and that : 32-bit ABIs should default to the MIPS32 ISA, when we are supporting : or will support some systems based on earlier 32-bit and 64-bit ISAs, : most notably MIPS-III. : o) Merge a new opcode file (and support code) from a later version of : binutils and add flags and code necessary to support Octeon-specific : instructions. This should also make merging opcodes for other modern : architectures easier. Great work Juli... I plan on merging my TBEMD branch after the dust from this settles down. Juts so people know... Warner From owner-freebsd-mips@FreeBSD.ORG Tue Jun 1 06:34:49 2010 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 D4B0D106564A; Tue, 1 Jun 2010 06:34:49 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A300E8FC0C; Tue, 1 Jun 2010 06:34:49 +0000 (UTC) Received: by pwj1 with SMTP id 1so466568pwj.13 for ; Mon, 31 May 2010 23:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=McINjBbrzy6XwvlfKQuz9/yUmXg4WBVSzzzarv32VZ0=; b=suY43g6DD22tuhD+Wa1gcs5/fgaw2NbW6LSLmSCv1rbmN5BY6jWnGskjYXUtxqo6N1 xtYVnWz+OXhZerq20SiNA/tqvaHOsz97xZs9h99C7s/QY6He96XYAhQkAqHv6bW7T+Yv PEHq7RAhU/Mt0kJQdiap2/A4jY5azmE49TF88= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QCnKV1voy9zxXnyCB9+5zKA11pb2NlEbGaZw3AuIqTV/bssiLmUNCBystq/8V71egS bHVL5acxNQByzmKl9Ty84oeU6XzvPc1zzhZ5igv74GZI6HBLUKUmw7doiFysT61XY9Wp PHV04Ux8yM/zx7DkyhJuNYpr91e9GTV3dG0LE= MIME-Version: 1.0 Received: by 10.140.58.2 with SMTP id g2mr4111831rva.172.1275374088958; Mon, 31 May 2010 23:34:48 -0700 (PDT) Received: by 10.141.4.3 with HTTP; Mon, 31 May 2010 23:34:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jun 2010 12:04:48 +0530 Message-ID: From: "C. Jayachandran" To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: HEADS UP: Toolchain changes coming soon. (Octeon, n32, n64) 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: Tue, 01 Jun 2010 06:34:49 -0000 On Tue, Jun 1, 2010 at 6:31 AM, Juli Mallett wrote: > Over the next day or two I am planning to merge changes to GCC and > binutils adding support for Octeon and the n32 and n64 ABIs, as well > as fixing a couple of bugs in our GCC spec. =A0Note that the > Octeon-related patches are necessary to support the Cavium Octeon > Simple Executive, which I am planning to import after these changes > have been committed, which will be terribly helpful for the Octeon > port, in particular a new network driver and hopefully soon crypto and > PCI support. > > If you have any questions or comments please get in touch with me. > The contents of the patch may shift some before commit as I do testing > on a wider variety of platforms. > > The full patch to GCC and binutils is at this URL, and I have > reproduced the description below: > > http://people.freebsd.org/~jmallett/mips-toolchain.diff > > o) Add TARGET_ABI to the MIPS toolchain build process. =A0This sets the > default ABI to one of o32, n32 or n64. =A0If it is not set, o32 is > assumed as that is the current default. > o) Set the default GCC cpu type to any specified TARGET_CPUTYPE. =A0This > is necessary to have a working "cc" if e.g. mips64 is specified, as > binutils will refuse to link objects using different ISAs in some > cases. > o) Add support for n32 and n64 ABIs to binutils and GCC. > o) Add additional required libgcc2 stubs for n32 and n64. > o) Add support for the "mips64r2" architecture to GCC. =A0Add the "octeon= " GCC seems to have added mips64r2 support in 4.4 (http://gcc.gnu.org/gcc-4.4/changes.html) which was a GPLv3 release, so I was under the impression that we could not merge it into FreeBSD. Is this a valid concern, or were you able to get the code re-licensed, Or (the option which is most likely) am I completely off track here :) Netlogic's next chip (XLP) too has MIPS64r2 ISA, so we are interested in getting support for this. Thanks, JC. From owner-freebsd-mips@FreeBSD.ORG Tue Jun 1 06:44:02 2010 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 51DBE106564A for ; Tue, 1 Jun 2010 06:44:02 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7BE8FC13 for ; Tue, 1 Jun 2010 06:44:01 +0000 (UTC) Received: by vws10 with SMTP id 10so2731347vws.13 for ; Mon, 31 May 2010 23:44:01 -0700 (PDT) Received: by 10.220.122.86 with SMTP id k22mr4228854vcr.165.1275374641085; Mon, 31 May 2010 23:44:01 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.220.199.70 with HTTP; Mon, 31 May 2010 23:43:41 -0700 (PDT) In-Reply-To: References: From: Juli Mallett Date: Mon, 31 May 2010 23:43:41 -0700 X-Google-Sender-Auth: Wh9OaqorVAF7eDMtkY1iLB7zEME Message-ID: To: "C. Jayachandran" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-mips@freebsd.org Subject: Re: HEADS UP: Toolchain changes coming soon. (Octeon, n32, n64) 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: Tue, 01 Jun 2010 06:44:02 -0000 On Mon, May 31, 2010 at 23:34, C. Jayachandran wrote: > GCC seems to have added mips64r2 support in 4.4 > (http://gcc.gnu.org/gcc-4.4/changes.html) which was a GPLv3 release, > so I was under the impression that we could not merge it into FreeBSD. > Is this a valid concern, or were you able to get the code re-licensed, > Or (the option which is most likely) am I completely off track here :) > > Netlogic's next chip (XLP) too has MIPS64r2 ISA, so we are interested > in getting support for this. Well, let me be clear about the extent of the support. There was already a mips32r2 stub which added support for a couple of things and I extended mips64 to mips64r2 in the same way. It's mostly just there to get mips64r2 instructions to work in binutils (i.e. to proxy the ISA level to the assembler.) I didn't use any GPLv3 sources as a reference, although a search later suggested that the trivial parts of the change (i.e. internally encoding mips64r2 as 65 much as mips32r2 is 33) were similar. If you look at the diff it's pretty clear that calling it support is pretty laughable except wrt being able to assemble inline assembly using those instructions, setting the right default with the assembler and support in GCC for rotate, seb and seh instructions. Is there specific functionality you need in GCC? Juli. From owner-freebsd-mips@FreeBSD.ORG Tue Jun 1 09:17:56 2010 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 7ECB4106568B; Tue, 1 Jun 2010 09:17:56 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4B6468FC12; Tue, 1 Jun 2010 09:17:56 +0000 (UTC) Received: by pva18 with SMTP id 18so89372pva.13 for ; Tue, 01 Jun 2010 02:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rm5sgBgCxy1QZqSt0B3JNK8iqAzsHdBj+SVACCWiM8k=; b=G3euW7PcjiWkdgOEGahalZjAixd+jCmJ89ZArwmewYjPfT5myXAaGgMjZuMI4WBKcV 5TZ0QUGl3ejV9H+rlfs9oN0lpbZyk2ai9nmAUlLDAtmROVsKOMwmQdErTo09lrO08EhZ hPCAGHLGWZd3FIfMGfw9mndjWi+8bKkAyuy8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Pdt6tCW7JrDOuDKNdqkqk3NU52wrv6VpJ1Lj5kSfEeV1ReII8JUF8r6b3QEVg2aeKa JZPuu5PHNkTk+owxS/2gHReLfLUlceCCiAuVGu6JYVAePO2yvUI64KwsJ31QJWb+vsVK C3luGCs8kSYAWz+qbzCKlG5FA/O/xW/U6QntU= MIME-Version: 1.0 Received: by 10.141.13.5 with SMTP id q5mr4242857rvi.280.1275383875578; Tue, 01 Jun 2010 02:17:55 -0700 (PDT) Received: by 10.141.4.3 with HTTP; Tue, 1 Jun 2010 02:17:55 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 Jun 2010 14:47:55 +0530 Message-ID: From: "C. Jayachandran" To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: HEADS UP: Toolchain changes coming soon. (Octeon, n32, n64) 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: Tue, 01 Jun 2010 09:17:56 -0000 On Tue, Jun 1, 2010 at 12:13 PM, Juli Mallett wrote: > On Mon, May 31, 2010 at 23:34, C. Jayachandran = wrote: >> GCC seems to have added mips64r2 support in 4.4 >> (http://gcc.gnu.org/gcc-4.4/changes.html) which was a GPLv3 release, >> so I was under the impression that we could not merge it into FreeBSD. >> Is this a valid concern, or were you able to get the code re-licensed, >> Or (the option which is most likely) am I completely off track here :) >> >> Netlogic's next chip (XLP) too has MIPS64r2 ISA, so we are interested >> in getting support for this. > > Well, let me be clear about the extent of the support. =A0There was > already a mips32r2 stub which added support for a couple of things and > I extended mips64 to mips64r2 in the same way. =A0It's mostly just there > to get mips64r2 instructions to work in binutils (i.e. to proxy the > ISA level to the assembler.) =A0I didn't use any GPLv3 sources as a > reference, although a search later suggested that the trivial parts of > the change (i.e. internally encoding mips64r2 as 65 much as mips32r2 > is 33) were similar. =A0If you look at the diff it's pretty clear that > calling it support is pretty laughable except wrt being able to > assemble inline assembly using those instructions, setting the right > default with the assembler and support in GCC for rotate, seb and seh > instructions. That clears it up, thanks. Looking at the patch, most of the changes seems to be in binutils, are these from a specific version of binutils? I am asking because I'm not sure how the FreeBSD toolchain is synchronized across architectures - are all architectures at the same version of binutils, or can each architecture decide to update its part of the tool-chain. > Is there specific functionality you need in GCC? Netlogic has some updates for GCC and binutils in its SDK. But they are not critical, and we have not merged these into the FreeBSD. I was not sure if I can get these changes into FreeBSD directly. JC. From owner-freebsd-mips@FreeBSD.ORG Tue Jun 1 09:23:27 2010 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 876CE1065673 for ; Tue, 1 Jun 2010 09:23:27 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 456008FC12 for ; Tue, 1 Jun 2010 09:23:26 +0000 (UTC) Received: by vws10 with SMTP id 10so2926633vws.13 for ; Tue, 01 Jun 2010 02:23:26 -0700 (PDT) Received: by 10.220.107.73 with SMTP id a9mr4389973vcp.65.1275384206192; Tue, 01 Jun 2010 02:23:26 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.220.199.70 with HTTP; Tue, 1 Jun 2010 02:23:06 -0700 (PDT) In-Reply-To: References: From: Juli Mallett Date: Tue, 1 Jun 2010 02:23:06 -0700 X-Google-Sender-Auth: eNfZ0p8JIChPEBYO9Q72-U5_25Q Message-ID: To: "C. Jayachandran" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: HEADS UP: Toolchain changes coming soon. (Octeon, n32, n64) 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: Tue, 01 Jun 2010 09:23:27 -0000 On Tue, Jun 1, 2010 at 02:17, C. Jayachandran wr= ote: > That clears it up, thanks. =A0Looking at the patch, most of the changes > seems to be in binutils, are these from a specific version of > binutils? =A0I am asking because I'm not sure how the FreeBSD toolchain > is synchronized across architectures - are all architectures at the > same version of binutils, or can each architecture decide to update > its part of the tool-chain. I pulled some files from a slightly more modern version of binutils from a Cavium SDK than ours and reduced differences to make the relevant parts of code match the older binutils API we provide, while still providing the newer opcode interface and a couple of nearby things. >> Is there specific functionality you need in GCC? > > Netlogic has some updates for GCC and binutils in its SDK. But they > are not critical, and we have not merged these into the FreeBSD. =A0I > was not sure if I can get these changes into FreeBSD directly. If Netlogic can GPLv2 their specific changes or reimplement them relative to FreeBSD's toolchain, I think we would want to coordinate to get them into the tree. Our goal is generally to produce a fully-working self-hosting system out of the box. That may change at some point, especially if Warner's work on supporting external toolchains better pans out well, but I think for now it's a reasonable goal. Note that my understanding is that David O'Brien is working on bringing in the last GPLv2 binutils which will make the differences required for mips64r2 and Octeon substantially-smaller and I would hope for Netlogic processors as well. Thanks, Juli. From owner-freebsd-mips@FreeBSD.ORG Wed Jun 2 12:36:32 2010 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 CF6941065676; Wed, 2 Jun 2010 12:36:32 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B06D8FC1D; Wed, 2 Jun 2010 12:36:32 +0000 (UTC) Received: by pxi7 with SMTP id 7so3115662pxi.13 for ; Wed, 02 Jun 2010 05:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YvgCZO0MiLRKA2SMuwAQGCahAEjKmtdGxwhX3dHMDrw=; b=cx/3xmH4ZOHUtWRDU3VZHL7FIYfWMKnUhrTa0sv3QHvDbVPKcsB72YxapIEFyemQz+ uy5a05IoRbOe1XmzhSY6ZtQuWmDIlvyHht0AFEBAFQbQ67pn1RXYxtaXbxRAEdz3qbXV 0cdCJ9khSLM8sNsYWtACSK3HvH8rQWMJV+O38= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lchYBxEGQryY/NjcRDWFhymXZeZyjUC86YpmCh+YILkZYuoKOVJ2UUv165GOiS7qaT i8PYquU7bul1zfGPnbiVaNmZV6j3ZTHUa40cGRpSrkIMbMfLm80dJMeaG5hexyDXa/1s PeJRjcz48mDHMIWxawh8+2GZPEBnLC+tAqS94= MIME-Version: 1.0 Received: by 10.141.188.4 with SMTP id q4mr6357068rvp.147.1275482192214; Wed, 02 Jun 2010 05:36:32 -0700 (PDT) Received: by 10.141.4.3 with HTTP; Wed, 2 Jun 2010 05:36:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 Jun 2010 18:06:32 +0530 Message-ID: From: "C. Jayachandran" To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: HEADS UP: Toolchain changes coming soon. (Octeon, n32, n64) 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: Wed, 02 Jun 2010 12:36:33 -0000 On Tue, Jun 1, 2010 at 2:53 PM, Juli Mallett wrote: > On Tue, Jun 1, 2010 at 02:17, C. Jayachandran = wrote: >> That clears it up, thanks. =A0Looking at the patch, most of the changes >> seems to be in binutils, are these from a specific version of >> binutils? =A0I am asking because I'm not sure how the FreeBSD toolchain >> is synchronized across architectures - are all architectures at the >> same version of binutils, or can each architecture decide to update >> its part of the tool-chain. > > I pulled some files from a slightly more modern version of binutils > from a Cavium SDK than ours and reduced differences to make the > relevant parts of code match the older binutils API we provide, while > still providing the newer opcode interface and a couple of nearby > things. > >>> Is there specific functionality you need in GCC? >> >> Netlogic has some updates for GCC and binutils in its SDK. But they >> are not critical, and we have not merged these into the FreeBSD. =A0I >> was not sure if I can get these changes into FreeBSD directly. > > If Netlogic can GPLv2 their specific changes or reimplement them > relative to FreeBSD's toolchain, I think we would want to coordinate > to get them into the tree. =A0Our goal is generally to produce a > fully-working self-hosting system out of the box. =A0That may change at > some point, especially if Warner's work on supporting external > toolchains better pans out well, but I think for now it's a reasonable > goal. Stock binutils and GCC works fine for XLR (it is mips64 compliant), so XLR is self-hosting with the current FreeBSD MIPS tool-chain. Our patch for GCC is for adding 'xlr' machine description and march/mtune options. The binutils patch is for a few XLR specific instructions for which we currently '.word' in assembly for. So both of these are not really needed. Also licensing should not be an issue here - I'll have a go at this once the other toolchain changes are in. > Note that my understanding is that David O'Brien is working on > bringing in the last GPLv2 binutils which will make the differences > required for mips64r2 and Octeon substantially-smaller and I would > hope for Netlogic processors as well. JC. From owner-freebsd-mips@FreeBSD.ORG Wed Jun 2 13:45:01 2010 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 0BA6C106564A; Wed, 2 Jun 2010 13:45:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 752518FC0C; Wed, 2 Jun 2010 13:45:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o52DaXjn038356; Wed, 2 Jun 2010 07:36:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 02 Jun 2010 07:36:44 -0600 (MDT) Message-Id: <20100602.073644.695112013731480233.imp@bsdimp.com> To: c.jayachandran@gmail.com From: "M. Warner Losh" In-Reply-To: References: X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jmallett@FreeBSD.org, freebsd-mips@FreeBSD.org Subject: Re: HEADS UP: Toolchain changes coming soon. (Octeon, n32, n64) 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: Wed, 02 Jun 2010 13:45:01 -0000 In message: "C. Jayachandran" writes: : On Tue, Jun 1, 2010 at 2:53 PM, Juli Mallett w= rote: : > On Tue, Jun 1, 2010 at 02:17, C. Jayachandran wrote: : >> That clears it up, thanks. =A0Looking at the patch, most of the ch= anges : >> seems to be in binutils, are these from a specific version of : >> binutils? =A0I am asking because I'm not sure how the FreeBSD tool= chain : >> is synchronized across architectures - are all architectures at th= e : >> same version of binutils, or can each architecture decide to updat= e : >> its part of the tool-chain. : > : > I pulled some files from a slightly more modern version of binutils= : > from a Cavium SDK than ours and reduced differences to make the : > relevant parts of code match the older binutils API we provide, whi= le : > still providing the newer opcode interface and a couple of nearby : > things. : > : >>> Is there specific functionality you need in GCC? : >> : >> Netlogic has some updates for GCC and binutils in its SDK. But the= y : >> are not critical, and we have not merged these into the FreeBSD. =A0= I : >> was not sure if I can get these changes into FreeBSD directly. : > : > If Netlogic can GPLv2 their specific changes or reimplement them : > relative to FreeBSD's toolchain, I think we would want to coordinat= e : > to get them into the tree. =A0Our goal is generally to produce a : > fully-working self-hosting system out of the box. =A0That may chang= e at : > some point, especially if Warner's work on supporting external : > toolchains better pans out well, but I think for now it's a reasona= ble : > goal. : = : Stock binutils and GCC works fine for XLR (it is mips64 compliant), s= o : XLR is self-hosting with the current FreeBSD MIPS tool-chain. Our : patch for GCC is for adding 'xlr' machine description and march/mtune= : options. The binutils patch is for a few XLR specific instructions fo= r : which we currently '.word' in assembly for. So both of these are not= : really needed. : = : Also licensing should not be an issue here - I'll have a go at this : once the other toolchain changes are in. : = : > Note that my understanding is that David O'Brien is working on : > bringing in the last GPLv2 binutils which will make the differences= : > required for mips64r2 and Octeon substantially-smaller and I would : > hope for Netlogic processors as well. One thing that I'm told, but haven't verified, is that the binutils from the XLR SDK breaks other mips platforms in subtle ways. Based on this assertion, I think it would be prudent to carefully review and test any proposed patches from that SDK. Warner From owner-freebsd-mips@FreeBSD.ORG Wed Jun 2 14:41:31 2010 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 5F6FB1065675; Wed, 2 Jun 2010 14:41:31 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1E08FC12; Wed, 2 Jun 2010 14:41:30 +0000 (UTC) Received: by pzk5 with SMTP id 5so3407069pzk.14 for ; Wed, 02 Jun 2010 07:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tP09f1wKyR33JDGw95pvhD7mEQkfUTcz4OZ4Ud/a7+M=; b=igIkPg2HGu5OC8uw2E3BvRI9Q1n+37H/3rHM2kkMRBmyRQZN0HqNVLo7HPtbOqlLh2 NcPUtnuKjNKK/txMaEl6ng6brrLM+RevYpwnVclwXTHtPQo94WDOixrXd+MHGWwT+KHG hLHX2L3FHsOexhHhcnsjCCG9rgSJzdym9xYgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wptEIrZ/yw5TmHCiPmgbCZQS/UhQ7V/S4tL/FVUmvrs2mf+NeeHt7T8k/QR2kL9dx5 Z7pbrGD6wvU3YRB0dDL0k3WzunXmvm4ywiq4cE/TxV945IGrakyie2apfHDWVDfiKRne HcPa8QisSkp32Ro9SAdlD31JgIL96gpxgYKIs= MIME-Version: 1.0 Received: by 10.140.248.8 with SMTP id v8mr6493575rvh.9.1275489690595; Wed, 02 Jun 2010 07:41:30 -0700 (PDT) Received: by 10.141.4.3 with HTTP; Wed, 2 Jun 2010 07:41:30 -0700 (PDT) In-Reply-To: <20100602.073644.695112013731480233.imp@bsdimp.com> References: <20100602.073644.695112013731480233.imp@bsdimp.com> Date: Wed, 2 Jun 2010 20:11:30 +0530 Message-ID: From: "C. Jayachandran" To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: HEADS UP: Toolchain changes coming soon. (Octeon, n32, n64) 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: Wed, 02 Jun 2010 14:41:31 -0000 On Wed, Jun 2, 2010 at 7:06 PM, M. Warner Losh wrote: > In message: > =A0 =A0 =A0 =A0 =A0 =A0"C. Jayachandran" write= s: > : On Tue, Jun 1, 2010 at 2:53 PM, Juli Mallett wro= te: > : > On Tue, Jun 1, 2010 at 02:17, C. Jayachandran wrote: > : >> That clears it up, thanks. =A0Looking at the patch, most of the chan= ges > : >> seems to be in binutils, are these from a specific version of > : >> binutils? =A0I am asking because I'm not sure how the FreeBSD toolch= ain > : >> is synchronized across architectures - are all architectures at the > : >> same version of binutils, or can each architecture decide to update > : >> its part of the tool-chain. > : > > : > I pulled some files from a slightly more modern version of binutils > : > from a Cavium SDK than ours and reduced differences to make the > : > relevant parts of code match the older binutils API we provide, while > : > still providing the newer opcode interface and a couple of nearby > : > things. > : > > : >>> Is there specific functionality you need in GCC? > : >> > : >> Netlogic has some updates for GCC and binutils in its SDK. But they > : >> are not critical, and we have not merged these into the FreeBSD. =A0= I > : >> was not sure if I can get these changes into FreeBSD directly. > : > > : > If Netlogic can GPLv2 their specific changes or reimplement them > : > relative to FreeBSD's toolchain, I think we would want to coordinate > : > to get them into the tree. =A0Our goal is generally to produce a > : > fully-working self-hosting system out of the box. =A0That may change = at > : > some point, especially if Warner's work on supporting external > : > toolchains better pans out well, but I think for now it's a reasonabl= e > : > goal. > : > : Stock binutils and GCC works fine for XLR (it is mips64 compliant), so > : XLR is self-hosting with the current FreeBSD MIPS tool-chain. =A0Our > : patch for GCC is for adding 'xlr' machine description and march/mtune > : options. The binutils patch is for a few XLR specific instructions for > : which we currently '.word' in assembly for. =A0So both of these are not > : really needed. > : > : Also licensing should not be an issue here - =A0I'll have a go at this > : once the other toolchain changes are in. > : > : > Note that my understanding is that David O'Brien is working on > : > bringing in the last GPLv2 binutils which will make the differences > : > required for mips64r2 and Octeon substantially-smaller and I would > : > hope for Netlogic processors as well. > > One thing that I'm told, but haven't verified, is that the binutils > from the XLR SDK breaks other mips platforms in subtle ways. =A0Based on > this assertion, I think it would be prudent to carefully review and > test any proposed patches from that SDK. Our gcc and binutils patches are in the latest releases (IIRC - GCC went in about 4.4 and binutils patches are in 2.20), so it has gone thru some testing. JC. From owner-freebsd-mips@FreeBSD.ORG Wed Jun 2 15:08:21 2010 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 E1565106566B; Wed, 2 Jun 2010 15:08:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6B0DC8FC08; Wed, 2 Jun 2010 15:08:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o52F4BkJ039415; Wed, 2 Jun 2010 09:04:11 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 02 Jun 2010 09:04:22 -0600 (MDT) Message-Id: <20100602.090422.862433495782007974.imp@bsdimp.com> To: c.jayachandran@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20100602.073644.695112013731480233.imp@bsdimp.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: HEADS UP: Toolchain changes coming soon. (Octeon, n32, n64) 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: Wed, 02 Jun 2010 15:08:21 -0000 In message: "C. Jayachandran" writes: : On Wed, Jun 2, 2010 at 7:06 PM, M. Warner Losh wrote= : : > In message: : > =A0 =A0 =A0 =A0 =A0 =A0"C. Jayachandran" = writes: : > : On Tue, Jun 1, 2010 at 2:53 PM, Juli Mallett wrote: : > : > On Tue, Jun 1, 2010 at 02:17, C. Jayachandran wrote: : > : >> That clears it up, thanks. =A0Looking at the patch, most of th= e changes : > : >> seems to be in binutils, are these from a specific version of : > : >> binutils? =A0I am asking because I'm not sure how the FreeBSD = toolchain : > : >> is synchronized across architectures - are all architectures a= t the : > : >> same version of binutils, or can each architecture decide to u= pdate : > : >> its part of the tool-chain. : > : > : > : > I pulled some files from a slightly more modern version of binu= tils : > : > from a Cavium SDK than ours and reduced differences to make the= : > : > relevant parts of code match the older binutils API we provide,= while : > : > still providing the newer opcode interface and a couple of near= by : > : > things. : > : > : > : >>> Is there specific functionality you need in GCC? : > : >> : > : >> Netlogic has some updates for GCC and binutils in its SDK. But= they : > : >> are not critical, and we have not merged these into the FreeBS= D. =A0I : > : >> was not sure if I can get these changes into FreeBSD directly.= : > : > : > : > If Netlogic can GPLv2 their specific changes or reimplement the= m : > : > relative to FreeBSD's toolchain, I think we would want to coord= inate : > : > to get them into the tree. =A0Our goal is generally to produce = a : > : > fully-working self-hosting system out of the box. =A0That may c= hange at : > : > some point, especially if Warner's work on supporting external : > : > toolchains better pans out well, but I think for now it's a rea= sonable : > : > goal. : > : : > : Stock binutils and GCC works fine for XLR (it is mips64 compliant= ), so : > : XLR is self-hosting with the current FreeBSD MIPS tool-chain. =A0= Our : > : patch for GCC is for adding 'xlr' machine description and march/m= tune : > : options. The binutils patch is for a few XLR specific instruction= s for : > : which we currently '.word' in assembly for. =A0So both of these a= re not : > : really needed. : > : : > : Also licensing should not be an issue here - =A0I'll have a go at= this : > : once the other toolchain changes are in. : > : : > : > Note that my understanding is that David O'Brien is working on : > : > bringing in the last GPLv2 binutils which will make the differe= nces : > : > required for mips64r2 and Octeon substantially-smaller and I wo= uld : > : > hope for Netlogic processors as well. : > : > One thing that I'm told, but haven't verified, is that the binutils= : > from the XLR SDK breaks other mips platforms in subtle ways. =A0Bas= ed on : > this assertion, I think it would be prudent to carefully review and= : > test any proposed patches from that SDK. : = : Our gcc and binutils patches are in the latest releases (IIRC - GCC : went in about 4.4 and binutils patches are in 2.20), so it has gone : thru some testing. On the one hand, that's cool! On the other, if they are in those releases, then it is GPLv3 code. FSF requires ownership assignment. How will there not be license issues? Warner From owner-freebsd-mips@FreeBSD.ORG Wed Jun 2 15:32:43 2010 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 078EC106568A; Wed, 2 Jun 2010 15:32:43 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C639F8FC17; Wed, 2 Jun 2010 15:32:42 +0000 (UTC) Received: by pwj1 with SMTP id 1so1414075pwj.13 for ; Wed, 02 Jun 2010 08:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tSidn337UvTxDbRgXExOg99Z4lYaT77CwGgc26u1pTg=; b=w+OohQ1D3aMtITN+p4VblSkWMWXu+uBX34V8hmD1k96f4YE7u/LRn6mteivDe2WfJR mEBy6iLhfpQSbEjozudCVCflK8qpITpomtzDo4/LW49ABbiT3pJM1+f8pYzXiDrfq3rN Fb4qwue4jr5CnT5JP2kYj65HHyhavvRN8kyHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=W0Ljj/uLB8G5v/xNI9ppRtJLudC3KNMsGzx3aYUYYsSe91NpbhkmNpxUcbUjqvrCso iLXn3PuOWzuGzkncVbWUCZwTI6q1iKWLrhUYGJosGHn0codlCDTJXEnuGRPZxkkd7/Cl KtQ/GtU6UU+Xb9VnZN7MvC+IHR7fLCPBPNdn4= MIME-Version: 1.0 Received: by 10.140.56.18 with SMTP id e18mr6610150rva.167.1275492762153; Wed, 02 Jun 2010 08:32:42 -0700 (PDT) Received: by 10.141.4.3 with HTTP; Wed, 2 Jun 2010 08:32:42 -0700 (PDT) In-Reply-To: <20100602.090422.862433495782007974.imp@bsdimp.com> References: <20100602.073644.695112013731480233.imp@bsdimp.com> <20100602.090422.862433495782007974.imp@bsdimp.com> Date: Wed, 2 Jun 2010 21:02:42 +0530 Message-ID: From: "C. Jayachandran" To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-mips@freebsd.org Subject: Re: HEADS UP: Toolchain changes coming soon. (Octeon, n32, n64) 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: Wed, 02 Jun 2010 15:32:43 -0000 On Wed, Jun 2, 2010 at 8:34 PM, M. Warner Losh wrote: > In message: > =A0 =A0 =A0 =A0 =A0 =A0"C. Jayachandran" write= s: > : On Wed, Jun 2, 2010 at 7:06 PM, M. Warner Losh wrote: > : > In message: > : > =A0 =A0 =A0 =A0 =A0 =A0"C. Jayachandran" w= rites: > : > : On Tue, Jun 1, 2010 at 2:53 PM, Juli Mallett = wrote: > : > : > On Tue, Jun 1, 2010 at 02:17, C. Jayachandran wrote: > : > : >> That clears it up, thanks. =A0Looking at the patch, most of the = changes > : > : >> seems to be in binutils, are these from a specific version of > : > : >> binutils? =A0I am asking because I'm not sure how the FreeBSD to= olchain > : > : >> is synchronized across architectures - are all architectures at = the > : > : >> same version of binutils, or can each architecture decide to upd= ate > : > : >> its part of the tool-chain. > : > : > > : > : > I pulled some files from a slightly more modern version of binuti= ls > : > : > from a Cavium SDK than ours and reduced differences to make the > : > : > relevant parts of code match the older binutils API we provide, w= hile > : > : > still providing the newer opcode interface and a couple of nearby > : > : > things. > : > : > > : > : >>> Is there specific functionality you need in GCC? > : > : >> > : > : >> Netlogic has some updates for GCC and binutils in its SDK. But t= hey > : > : >> are not critical, and we have not merged these into the FreeBSD.= =A0I > : > : >> was not sure if I can get these changes into FreeBSD directly. > : > : > > : > : > If Netlogic can GPLv2 their specific changes or reimplement them > : > : > relative to FreeBSD's toolchain, I think we would want to coordin= ate > : > : > to get them into the tree. =A0Our goal is generally to produce a > : > : > fully-working self-hosting system out of the box. =A0That may cha= nge at > : > : > some point, especially if Warner's work on supporting external > : > : > toolchains better pans out well, but I think for now it's a reaso= nable > : > : > goal. > : > : > : > : Stock binutils and GCC works fine for XLR (it is mips64 compliant),= so > : > : XLR is self-hosting with the current FreeBSD MIPS tool-chain. =A0Ou= r > : > : patch for GCC is for adding 'xlr' machine description and march/mtu= ne > : > : options. The binutils patch is for a few XLR specific instructions = for > : > : which we currently '.word' in assembly for. =A0So both of these are= not > : > : really needed. > : > : > : > : Also licensing should not be an issue here - =A0I'll have a go at t= his > : > : once the other toolchain changes are in. > : > : > : > : > Note that my understanding is that David O'Brien is working on > : > : > bringing in the last GPLv2 binutils which will make the differenc= es > : > : > required for mips64r2 and Octeon substantially-smaller and I woul= d > : > : > hope for Netlogic processors as well. > : > > : > One thing that I'm told, but haven't verified, is that the binutils > : > from the XLR SDK breaks other mips platforms in subtle ways. =A0Based= on > : > this assertion, I think it would be prudent to carefully review and > : > test any proposed patches from that SDK. > : > : Our gcc and binutils patches are in the latest releases (IIRC - GCC > : went in about 4.4 and binutils patches are in 2.20), so it has gone > : thru some testing. > > On the one hand, that's cool! > > On the other, if they are in those releases, then it is GPLv3 code. > FSF requires ownership assignment. =A0How will there not be license > issues? We have these changes against the older (GPLv2) tool-chains in the SDK. I brought up the later versions just to clarify the testing and review status. JC. From owner-freebsd-mips@FreeBSD.ORG Wed Jun 2 18:31:16 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4BE9106584C; Wed, 2 Jun 2010 18:31:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 86B908FC19; Wed, 2 Jun 2010 18:31:16 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o52IVFGB088931; Wed, 2 Jun 2010 14:31:15 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o52IVFJH088930; Wed, 2 Jun 2010 18:31:15 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 2 Jun 2010 18:31:15 GMT Message-Id: <201006021831.o52IVFJH088930@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 18:31:17 -0000 TB --- 2010-06-02 18:21:16 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-02 18:21:16 - starting HEAD tinderbox run for mips/mips TB --- 2010-06-02 18:21:16 - cleaning the object tree TB --- 2010-06-02 18:21:24 - cvsupping the source tree TB --- 2010-06-02 18:21:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-06-02 18:21:56 - building world TB --- 2010-06-02 18:21:56 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-02 18:21:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-02 18:21:56 - TARGET=mips TB --- 2010-06-02 18:21:56 - TARGET_ARCH=mips TB --- 2010-06-02 18:21:56 - TZ=UTC TB --- 2010-06-02 18:21:56 - __MAKE_CONF=/dev/null TB --- 2010-06-02 18:21:56 - cd /src TB --- 2010-06-02 18:21:56 - /usr/bin/make -B buildworld >>> World build started on Wed Jun 2 18:21:57 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] {standard input}:427: Error: opcode not supported on this processor: mips1 (mips1) `ll $4,16($2)' {standard input}:429: Error: opcode not supported on this processor: mips1 (mips1) `sc $4,16($2)' {standard input}:1142: Error: opcode not supported on this processor: mips1 (mips1) `sync' {standard input}:1156: Error: opcode not supported on this processor: mips1 (mips1) `ll $5,12($3)' {standard input}:1158: Error: opcode not supported on this processor: mips1 (mips1) `sc $5,12($3)' {standard input}:1220: Error: opcode not supported on this processor: mips1 (mips1) `ll $6,12($2)' {standard input}:1223: Error: opcode not supported on this processor: mips1 (mips1) `sc $6,12($2)' {standard input}:1231: Error: opcode not supported on this processor: mips1 (mips1) `sync' *** Error code 1 Stop in /src/lib/libc. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-02 18:31:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-02 18:31:15 - ERROR: failed to build world TB --- 2010-06-02 18:31:15 - 424.33 user 85.25 system 598.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-mips@FreeBSD.ORG Thu Jun 3 05:30:06 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0975C1065670 for ; Thu, 3 Jun 2010 05:30:06 +0000 (UTC) (envelope-from alc@imimic.com) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id C87C88FC0C for ; Thu, 3 Jun 2010 05:30:05 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id BE6F12C2AAC for ; Wed, 2 Jun 2010 23:59:27 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QvJxFThEkpU5; Wed, 2 Jun 2010 23:59:18 -0500 (CDT) 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 DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 333682C2A81; Wed, 2 Jun 2010 23:59:17 -0500 (CDT) Message-ID: <4C0736A5.1010101@imimic.com> Date: Wed, 02 Jun 2010 23:59:17 -0500 From: Alan Cox Organization: iMimic Networking, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100501) MIME-Version: 1.0 To: mips@freebsd.org Content-Type: multipart/mixed; boundary="------------070309000303080603080902" Cc: Alan Cox Subject: init_pte_prot() patch 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, 03 Jun 2010 05:30:06 -0000 This is a multi-part message in MIME format. --------------070309000303080603080902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I would appreciate it if someone would test the attached patch. (A "buildworld" would probably suffice.) Essentially, it does two things: 1. The virtual memory system only cares about the contents of a page's dirty field if that page is managed (i.e., it is pageable). And, in fact, if you survey the calls to vm_page_dirty() in the MIPS or any other pmap, they are generally conditioned on the mapping having been for a managed page. The MIPS pmap_enter() is an exception to this rule. It is unconditionally calling vm_page_dirty() on any page mapped within the kernel address space, managed or otherwise. In fact, it is highly unusual for pmap_enter() to be calling vm_page_dirty() on the page being mapped, regardless of whether it is managed. This call to vm_page_dirty() shouldn't be needed if change #2 below is also made. The attached patch eliminates the call. 2. Since the virtual memory system only cares about the contents of a page's dirty field if that page is managed, then dirty bit emulation need only be performed on managed pages. At present, init_pte_prot() skips emulation if the address being mapped is in the kernel. However, this is not really the right condition to test for. There do exist some managed pages in the kernel address space, and it is also possible through System V shared memory to have unmanaged pages in the user address space. The attached patch bases the emulation decision on whether the page is managed. Thanks, Alan --------------070309000303080603080902 Content-Type: text/plain; name="init_pte_prot.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="init_pte_prot.patch" Index: mips/mips/pmap.c =================================================================== --- mips/mips/pmap.c (revision 208667) +++ mips/mips/pmap.c (working copy) @@ -3067,26 +3067,20 @@ page_is_managed(vm_offset_t pa) static int init_pte_prot(vm_offset_t va, vm_page_t m, vm_prot_t prot) { - int rw = 0; + int rw; if (!(prot & VM_PROT_WRITE)) rw = PTE_ROPAGE; - else { - if (va >= VM_MIN_KERNEL_ADDRESS) { - /* - * Don't bother to trap on kernel writes, just - * record page as dirty. - */ + else if ((m->flags & (PG_FICTITIOUS | PG_UNMANAGED)) == 0) { + if ((m->md.pv_flags & PV_TABLE_MOD) != 0) rw = PTE_RWPAGE; - vm_page_dirty(m); - } else if ((m->md.pv_flags & PV_TABLE_MOD) || - m->dirty == VM_PAGE_BITS_ALL) - rw = PTE_RWPAGE; else rw = PTE_CWPAGE; vm_page_flag_set(m, PG_WRITEABLE); - } - return rw; + } else + /* Needn't emulate a modified bit for unmanaged pages. */ + rw = PTE_RWPAGE; + return (rw); } /* --------------070309000303080603080902-- From owner-freebsd-mips@FreeBSD.ORG Thu Jun 3 06:01:56 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EADF1065686 for ; Thu, 3 Jun 2010 06:01:56 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D9ECA8FC14 for ; Thu, 3 Jun 2010 06:01:55 +0000 (UTC) Received: by gwj23 with SMTP id 23so6202245gwj.13 for ; Wed, 02 Jun 2010 23:01:55 -0700 (PDT) Received: by 10.229.248.2 with SMTP id me2mr1750002qcb.44.1275543292315; Wed, 02 Jun 2010 22:34:52 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.220.199.70 with HTTP; Wed, 2 Jun 2010 22:34:32 -0700 (PDT) In-Reply-To: <4C0736A5.1010101@imimic.com> References: <4C0736A5.1010101@imimic.com> From: Juli Mallett Date: Wed, 2 Jun 2010 22:34:32 -0700 X-Google-Sender-Auth: DBc8WU9HF7XyX0Kyr9WMouuP-WQ Message-ID: To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alan Cox , mips@freebsd.org Subject: Re: init_pte_prot() patch 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, 03 Jun 2010 06:01:56 -0000 Hi Alan, On Wed, Jun 2, 2010 at 21:59, Alan Cox wrote: > I would appreciate it if someone would test the attached patch. =A0(A > "buildworld" would probably suffice.) =A0Essentially, it does two things: Sorry I didn't respond to this when you sent it to me. > 1. The virtual memory system only cares about the contents of a page's di= rty > field if that page is managed (i.e., it is pageable). =A0And, in fact, if= you > survey the calls to vm_page_dirty() in the MIPS or any other pmap, they a= re > generally conditioned on the mapping having been for a managed page. > > The MIPS pmap_enter() is an exception to this rule. =A0It is unconditiona= lly > calling vm_page_dirty() on any page mapped within the kernel address spac= e, > managed or otherwise. =A0In fact, it is highly unusual for pmap_enter() t= o be > calling vm_page_dirty() on the page being mapped, regardless of whether i= t > is managed. =A0This call to vm_page_dirty() shouldn't be needed if change= #2 > below is also made. =A0The attached patch eliminates the call. I believe that the reason the MIPS pmap does that is because PTE_RWPAGE includes PTE_M which is the TLB dirty bit. This means that we won't get exceptions when that page is modified, and so MIPS is pre-dirtying the VM page to allow it to make that optimization. At least, that's what the intent appears to be. Whether that's a correct model for the interaction between pmap and the VM system's management of those kernel pages, I don't know. Juli. From owner-freebsd-mips@FreeBSD.ORG Thu Jun 3 06:23:39 2010 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8027F1065670; Thu, 3 Jun 2010 06:23:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2532A8FC0A; Thu, 3 Jun 2010 06:23:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o536Fud4048193; Thu, 3 Jun 2010 00:15:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 03 Jun 2010 00:16:08 -0600 (MDT) Message-Id: <20100603.001608.628446057294691926.imp@bsdimp.com> To: jmallett@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <4C0736A5.1010101@imimic.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: alc@imimic.com, mips@FreeBSD.org, alc@cs.rice.edu Subject: Re: init_pte_prot() patch 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, 03 Jun 2010 06:23:39 -0000 In message: Juli Mallett writes: : Hi Alan, : = : On Wed, Jun 2, 2010 at 21:59, Alan Cox wrote: : > I would appreciate it if someone would test the attached patch. =A0= (A : > "buildworld" would probably suffice.) =A0Essentially, it does two t= hings: : = : Sorry I didn't respond to this when you sent it to me. : = : > 1. The virtual memory system only cares about the contents of a pag= e's dirty : > field if that page is managed (i.e., it is pageable). =A0And, in fa= ct, if you : > survey the calls to vm_page_dirty() in the MIPS or any other pmap, = they are : > generally conditioned on the mapping having been for a managed page= .= : > : > The MIPS pmap_enter() is an exception to this rule. =A0It is uncond= itionally : > calling vm_page_dirty() on any page mapped within the kernel addres= s space, : > managed or otherwise. =A0In fact, it is highly unusual for pmap_ent= er() to be : > calling vm_page_dirty() on the page being mapped, regardless of whe= ther it : > is managed. =A0This call to vm_page_dirty() shouldn't be needed if = change #2 : > below is also made. =A0The attached patch eliminates the call. : = : I believe that the reason the MIPS pmap does that is because : PTE_RWPAGE includes PTE_M which is the TLB dirty bit. This means tha= t : we won't get exceptions when that page is modified, and so MIPS is : pre-dirtying the VM page to allow it to make that optimization. At : least, that's what the intent appears to be. Whether that's a correc= t : model for the interaction between pmap and the VM system's management= : of those kernel pages, I don't know. On MIPS, the hardware is such that the 'M' bit in the PTE needs to be set in order to write to the page. So we need to set it on pages the kernel needs to write, otherwise we take a TLB exception on first write. It is cheaper to pre-dirty kernel pages by setting the M bit in the TLB entry than to take the TLB miss and set it there. It isn't clear from me that this change takes that into account. But it also is rare that things are clear to me in the vm layer without an hour of careful study :) Warner From owner-freebsd-mips@FreeBSD.ORG Thu Jun 3 06:28:43 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8BBB1065692 for ; Thu, 3 Jun 2010 06:28:43 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id BCD198FC28 for ; Thu, 3 Jun 2010 06:28:43 +0000 (UTC) Received: by pxi7 with SMTP id 7so3636156pxi.13 for ; Wed, 02 Jun 2010 23:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+uxwLRjXuL6kMQYDYtJfllxiSRbYzTx638gc8vPOeNQ=; b=lveEpl+1XDdkap57SDqeecSOei32WVIW0Ic6yRRU4hjANKxEAq2ghh7rfNJDc//CG6 40uC2gc81h/0bD4xBNLeEtLdoQeUdKORxUd/+o/PlvEmYHj3F0fg+0uCLevOdL0qw08N 7cgsuLw/BNCW+RnJ2vyja6qr6kF+ANqqWCD4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ubXlPLOE/Wmbglc9ZvUTd/mApOJ/yuCXWYwpMNe29RNrjB5MyL96t8jx057zmZKV23 FMlsoG8Tp+xI+MS8Typ6krRwu9rsZOdMm6yp6iorZYq+y1CidYj6hSBvi5HDQETtzirp O/Sl37PB/yJzIpjY9l3VNd5PlHpm7T0jCwa3U= MIME-Version: 1.0 Received: by 10.141.124.5 with SMTP id b5mr7756228rvn.68.1275546523363; Wed, 02 Jun 2010 23:28:43 -0700 (PDT) Received: by 10.141.4.3 with HTTP; Wed, 2 Jun 2010 23:28:43 -0700 (PDT) In-Reply-To: <4C0736A5.1010101@imimic.com> References: <4C0736A5.1010101@imimic.com> Date: Thu, 3 Jun 2010 11:58:43 +0530 Message-ID: From: "C. Jayachandran" To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alan Cox , mips@freebsd.org Subject: Re: init_pte_prot() patch 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, 03 Jun 2010 06:28:44 -0000 On Thu, Jun 3, 2010 at 10:29 AM, Alan Cox wrote: > I would appreciate it if someone would test the attached patch. =A0(A > "buildworld" would probably suffice.) =A0Essentially, it does two things: > > 1. The virtual memory system only cares about the contents of a page's di= rty > field if that page is managed (i.e., it is pageable). =A0And, in fact, if= you > survey the calls to vm_page_dirty() in the MIPS or any other pmap, they a= re > generally conditioned on the mapping having been for a managed page. > > The MIPS pmap_enter() is an exception to this rule. =A0It is unconditiona= lly > calling vm_page_dirty() on any page mapped within the kernel address spac= e, > managed or otherwise. =A0In fact, it is highly unusual for pmap_enter() t= o be > calling vm_page_dirty() on the page being mapped, regardless of whether i= t > is managed. =A0This call to vm_page_dirty() shouldn't be needed if change= #2 > below is also made. =A0The attached patch eliminates the call. > > 2. Since the virtual memory system only cares about the contents of a pag= e's > dirty field if that page is managed, then dirty bit emulation need only b= e > performed on managed pages. =A0At present, init_pte_prot() skips emulatio= n if > the address being mapped is in the kernel. =A0However, this is not really= the > right condition to test for. =A0There do exist some managed pages in the > kernel address space, and it is also possible through System V shared mem= ory > to have unmanaged pages in the user address space. =A0The attached patch = bases > the emulation decision on whether the page is managed. I have added this patch to my buildworld test (make -j128 buildworld on a 8-core MIPS SoC) and it seems to be holding up. It will take a few hours to run over NFS - will update if I get anything. JC. From owner-freebsd-mips@FreeBSD.ORG Thu Jun 3 07:26:45 2010 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E593F1065670 for ; Thu, 3 Jun 2010 07:26:45 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id B16DB8FC0A for ; Thu, 3 Jun 2010 07:26:45 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id F1A8C2C2AEB; Thu, 3 Jun 2010 02:01:47 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C1qHSiyINKIn; Thu, 3 Jun 2010 02:01:40 -0500 (CDT) 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 DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id C9D0B2C2B32; Thu, 3 Jun 2010 02:01:39 -0500 (CDT) Message-ID: <4C075353.4030407@cs.rice.edu> Date: Thu, 03 Jun 2010 02:01:39 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100501) MIME-Version: 1.0 To: "M. Warner Losh" References: <4C0736A5.1010101@imimic.com> <20100603.001608.628446057294691926.imp@bsdimp.com> In-Reply-To: <20100603.001608.628446057294691926.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jmallett@FreeBSD.org, mips@FreeBSD.org, Alan Cox Subject: Re: init_pte_prot() patch 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, 03 Jun 2010 07:26:46 -0000 M. Warner Losh wrote: > In message: > Juli Mallett writes: > : Hi Alan, > : > : On Wed, Jun 2, 2010 at 21:59, Alan Cox wrote: > : > I would appreciate it if someone would test the attached patch. (A > : > "buildworld" would probably suffice.) Essentially, it does two things: > : > : Sorry I didn't respond to this when you sent it to me. > : > : > 1. The virtual memory system only cares about the contents of a page's dirty > : > field if that page is managed (i.e., it is pageable). And, in fact, if you > : > survey the calls to vm_page_dirty() in the MIPS or any other pmap, they are > : > generally conditioned on the mapping having been for a managed page. > : > > : > The MIPS pmap_enter() is an exception to this rule. It is unconditionally > : > calling vm_page_dirty() on any page mapped within the kernel address space, > : > managed or otherwise. In fact, it is highly unusual for pmap_enter() to be > : > calling vm_page_dirty() on the page being mapped, regardless of whether it > : > is managed. This call to vm_page_dirty() shouldn't be needed if change #2 > : > below is also made. The attached patch eliminates the call. > : > : I believe that the reason the MIPS pmap does that is because > : PTE_RWPAGE includes PTE_M which is the TLB dirty bit. This means that > : we won't get exceptions when that page is modified, and so MIPS is > : pre-dirtying the VM page to allow it to make that optimization. At > : least, that's what the intent appears to be. Whether that's a correct > : model for the interaction between pmap and the VM system's management > : of those kernel pages, I don't know. > > On MIPS, the hardware is such that the 'M' bit in the PTE needs to be > set in order to write to the page. So we need to set it on pages the > kernel needs to write, otherwise we take a TLB exception on first > write. It is cheaper to pre-dirty kernel pages by setting the M bit > in the TLB entry than to take the TLB miss and set it there. > > It isn't clear from me that this change takes that into account. But > it also is rare that things are clear to me in the vm layer without an > hour of careful study :) > It's handled by this case: ... } else /* Needn't emulate a modified bit for unmanaged pages. */ rw = PTE_RWPAGE; Alan From owner-freebsd-mips@FreeBSD.ORG Thu Jun 3 07:26:46 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E526C106564A for ; Thu, 3 Jun 2010 07:26:45 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id B17488FC0C for ; Thu, 3 Jun 2010 07:26:45 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 4AE3C2C2AD0; Thu, 3 Jun 2010 01:54:25 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RrnoBAD2sUhI; Thu, 3 Jun 2010 01:54:17 -0500 (CDT) 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 DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 3EDFF2C2A8E; Thu, 3 Jun 2010 01:54:17 -0500 (CDT) Message-ID: <4C075196.4050101@cs.rice.edu> Date: Thu, 03 Jun 2010 01:54:14 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100501) MIME-Version: 1.0 To: Juli Mallett References: <4C0736A5.1010101@imimic.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mips@freebsd.org, Alan Cox Subject: Re: init_pte_prot() patch 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, 03 Jun 2010 07:26:46 -0000 Juli Mallett wrote: > Hi Alan, > > On Wed, Jun 2, 2010 at 21:59, Alan Cox wrote: > >> I would appreciate it if someone would test the attached patch. (A >> "buildworld" would probably suffice.) Essentially, it does two things: >> > > Sorry I didn't respond to this when you sent it to me. > > >> 1. The virtual memory system only cares about the contents of a page's dirty >> field if that page is managed (i.e., it is pageable). And, in fact, if you >> survey the calls to vm_page_dirty() in the MIPS or any other pmap, they are >> generally conditioned on the mapping having been for a managed page. >> >> The MIPS pmap_enter() is an exception to this rule. It is unconditionally >> calling vm_page_dirty() on any page mapped within the kernel address space, >> managed or otherwise. In fact, it is highly unusual for pmap_enter() to be >> calling vm_page_dirty() on the page being mapped, regardless of whether it >> is managed. This call to vm_page_dirty() shouldn't be needed if change #2 >> below is also made. The attached patch eliminates the call. >> > > I believe that the reason the MIPS pmap does that is because > PTE_RWPAGE includes PTE_M which is the TLB dirty bit. Yes, PTE_M and PTE_RW are aliases for the same bit. > ... This means that > we won't get exceptions when that page is modified, and so MIPS is > pre-dirtying the VM page to allow it to make that optimization. Just to be clear, vm_page_dirty() sets the machine-independent layer's dirty field, not the PTE_M bit in the PTE. By removing the call to vm_page_dirty(), I am not eliminating the optimization. But, I am eliminating a lot of needless calls to vm_page_dirty(). As for the optimization of presetting PTE_M, I will argue that it should be based on whether or not the page is managed, not whether or not it is being mapped at a kernel virtual address. There can exist unmanaged pages in user space on which this optimization could also be applied but is not today. My patch fixes that. If the page is unmanaged, whether it is in the kernel address space or in a user address, PTE_M will be preset by my patch. Virtually all kernel pages are unmanaged. There do exist a very few managed pages in the kernel address space. The old code always preset PTE_M for these pages if the mapping was writeable. With my patch, these mappings may not have PTE_M preset if the first access is a read vm_fault() rather than a write vm_fault(). If, however, the first access is a write vm_fault(), there will not be a subsequent emulation trap. > ... At > least, that's what the intent appears to be. Whether that's a correct > model for the interaction between pmap and the VM system's management > of those kernel pages, I don't know. > > Look at it this way: They were using the wrong information from the virtual memory system to implement their optimization. The one worry that I have about the patch is that the dirty bit emulation code may be rusty when it comes to handling dirty bit emulation traps for the kernel address space. The code is there, but likely not used recently. Alan > Juli. > From owner-freebsd-mips@FreeBSD.ORG Fri Jun 4 13:52:59 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A08CE1065674; Fri, 4 Jun 2010 13:52:59 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by mx1.freebsd.org (Postfix) with ESMTP id 6EE3B8FC0C; Fri, 4 Jun 2010 13:52:59 +0000 (UTC) Received: by pzk5 with SMTP id 5so657174pzk.14 for ; Fri, 04 Jun 2010 06:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LckJ0ey0Z9oRokbwknPd/6aka3iVkDBPlNba1j2HqLg=; b=pFibBQKg4MjiMqf/ccoFb0vXR5FiASf8q8k07fzjbnOIDTIHIwa9uS5yrX8dEdBUhA VrMLMKZsCXjxoSQTv98zkfyz+vwK3Jt3Wyn7/z21woinDjwybTvqIJ83/ETtZs3FJV8K M6Zd9Qw74KaFF7ailGTdYniDsHfVBj0s9wbD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fU4fYbS7rGsEddnu79BMQwngabxeYq6aDw4WHULhbVL48oec9QI3fZnkNoa0IPbTZQ VEd2KjC0oj318IV7wAzDzaRvytY16YboXg0AZ3DpAJUq52oQTwxZ8yvupECtwKq0sMun 3mgQkK3HKRzxFVc12/S/WHGRN/TvHdj1cydWg= MIME-Version: 1.0 Received: by 10.141.187.12 with SMTP id o12mr8848257rvp.43.1275659578711; Fri, 04 Jun 2010 06:52:58 -0700 (PDT) Received: by 10.141.4.3 with HTTP; Fri, 4 Jun 2010 06:52:58 -0700 (PDT) In-Reply-To: <4C075196.4050101@cs.rice.edu> References: <4C0736A5.1010101@imimic.com> <4C075196.4050101@cs.rice.edu> Date: Fri, 4 Jun 2010 19:22:58 +0530 Message-ID: From: "C. Jayachandran" To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mips@freebsd.org Subject: Re: init_pte_prot() patch 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: Fri, 04 Jun 2010 13:52:59 -0000 On Thu, Jun 3, 2010 at 12:24 PM, Alan Cox wrote: > Juli Mallett wrote: >> >> Hi Alan, >> >> On Wed, Jun 2, 2010 at 21:59, Alan Cox wrote: >> >>> >>> I would appreciate it if someone would test the attached patch. =A0(A >>> "buildworld" would probably suffice.) =A0Essentially, it does two thing= s: >>> >> >> Sorry I didn't respond to this when you sent it to me. >> >> >>> >>> 1. The virtual memory system only cares about the contents of a page's >>> dirty >>> field if that page is managed (i.e., it is pageable). =A0And, in fact, = if >>> you >>> survey the calls to vm_page_dirty() in the MIPS or any other pmap, they >>> are >>> generally conditioned on the mapping having been for a managed page. >>> >>> The MIPS pmap_enter() is an exception to this rule. =A0It is >>> unconditionally >>> calling vm_page_dirty() on any page mapped within the kernel address >>> space, >>> managed or otherwise. =A0In fact, it is highly unusual for pmap_enter()= to >>> be >>> calling vm_page_dirty() on the page being mapped, regardless of whether >>> it >>> is managed. =A0This call to vm_page_dirty() shouldn't be needed if chan= ge >>> #2 >>> below is also made. =A0The attached patch eliminates the call. >>> >> >> I believe that the reason the MIPS pmap does that is because >> PTE_RWPAGE includes PTE_M which is the TLB dirty bit. > > Yes, PTE_M and PTE_RW are aliases for the same bit. > >> ... =A0This means that >> we won't get exceptions when that page is modified, and so MIPS is >> pre-dirtying the VM page to allow it to make that optimization. > > Just to be clear, vm_page_dirty() sets the machine-independent layer's di= rty > field, not the PTE_M bit in the PTE. =A0By removing the call to > vm_page_dirty(), I am not eliminating the optimization. =A0But, I am > eliminating a lot of needless calls to vm_page_dirty(). > > As for the optimization of presetting PTE_M, I will argue that it should = be > based on whether or not the page is managed, not whether or not it is bei= ng > mapped at a kernel virtual address. =A0There can exist unmanaged pages in= user > space on which this optimization could also be applied but is not today. = =A0My > patch fixes that. =A0If the page is unmanaged, whether it is in the kerne= l > address space or in a user address, PTE_M will be preset by my patch. > =A0Virtually all kernel pages are unmanaged. > > There do exist a very few managed pages in the kernel address space. =A0T= he > old code always preset PTE_M for these pages if the mapping was writeable= . > =A0With my patch, these mappings may not have PTE_M preset if the first a= ccess > is a read vm_fault() rather than a write vm_fault(). =A0If, however, the = first > access is a write vm_fault(), there will not be a subsequent emulation tr= ap. > >> ... =A0At >> least, that's what the intent appears to be. =A0Whether that's a correct >> model for the interaction between pmap and the VM system's management >> of those kernel pages, I don't know. >> > > Look at it this way: They were using the wrong information from the virtu= al > memory system to implement their optimization. > > The one worry that I have about the patch is that the dirty bit emulation > code may be rusty when it comes to handling dirty bit emulation traps for > the kernel address space. =A0The code is there, but likely not used recen= tly. I have tested a few SMP buildworld runs with this patch and it works so far= . JC. From owner-freebsd-mips@FreeBSD.ORG Fri Jun 4 15:19:49 2010 Return-Path: Delivered-To: freebsd-mips@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE26E1065677; Fri, 4 Jun 2010 15:19:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B5DEB8FC16; Fri, 4 Jun 2010 15:19:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o54FJnID012184; Fri, 4 Jun 2010 15:19:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o54FJnkX012180; Fri, 4 Jun 2010 15:19:49 GMT (envelope-from linimon) Date: Fri, 4 Jun 2010 15:19:49 GMT Message-Id: <201006041519.o54FJnkX012180@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-mips@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: misc/147471: [includes] [patch] whitespace discrepancy in sys/mips/include/memdev.h 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: Fri, 04 Jun 2010 15:19:50 -0000 Old Synopsis: [patch] whitespace discrepancy in sys/mips/include/memdev.h New Synopsis: [includes] [patch] whitespace discrepancy in sys/mips/include/memdev.h Responsible-Changed-From-To: freebsd-bugs->freebsd-mips Responsible-Changed-By: linimon Responsible-Changed-When: Fri Jun 4 15:19:13 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). Note that there is no 'mips' category in GNATS (yet). http://www.freebsd.org/cgi/query-pr.cgi?pr=147471 From owner-freebsd-mips@FreeBSD.ORG Fri Jun 4 17:14:17 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E6F21065675; Fri, 4 Jun 2010 17:14:17 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id E403A8FC16; Fri, 4 Jun 2010 17:14:16 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 676D62C2B02; Fri, 4 Jun 2010 12:14:16 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lH0o2e0-ABRO; Fri, 4 Jun 2010 12:14:08 -0500 (CDT) 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 DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 2982C2C2A63; Fri, 4 Jun 2010 12:14:08 -0500 (CDT) Message-ID: <4C09345F.9040300@cs.rice.edu> Date: Fri, 04 Jun 2010 12:14:07 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.24 (X11/20100501) MIME-Version: 1.0 To: "C. Jayachandran" References: <201005271005.o4RA5eVu032269@svn.freebsd.org> <4C058145.3000707@cs.rice.edu> <4C05F9BC.40409@cs.rice.edu> <4C0731A5.7090301@cs.rice.edu> <4C07E07B.9060802@cs.rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Jayachandran C." , Konstantin Belousov , Alan Cox , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips 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: Fri, 04 Jun 2010 17:14:17 -0000 C. Jayachandran wrote: > On Thu, Jun 3, 2010 at 10:33 PM, Alan Cox wrote: > [snip] > >> Add a static counter to pmap_ptpgzone_allocf(). When the counter reaches >> some not-too-small prime number, don't call vm_phys_alloc_contig(), instead >> set "m" to NULL and reset the counter to zero. Setting "m" to NULL should >> then trigger the vm_contig_grow_cache() call. Make sense? >> > > Is this to move the vm_contig_grow_cache() out of the > pmap_ptpgzone_allocf() and into the function calling uma_zalloc()? I > am wondering why the prime number is needed. > > Another implementation I had thought about was to have a kernel > process maintain a pool of direct mapped pages for MIPS. This will be > woken up if the pool goes below a low water mark - any comments on > this? > > Here is how the page table page allocation should be done. It's not much harder than the vm_contig_grow_cache() change. 1. Look at vm/vm_phys.c, in particular, vm_phys_init(). Create a new freelist, like VM_FREELIST_ISADMA, for the direct-mapped memory on MIPS. Perhaps, call it VM_FREELIST_LOWMEM. The controlling macros should be defined in mips/include/vmparam.h. 2. Trivially refactor vm_phys_alloc_pages(). Specifically, take the body of the outer for loop and make it a new function, vm_phys_alloc_freelist(), that takes the variable "flind" as a parameter. 3. Eliminate the UMA zone for page table pages. In place of vm_phys_alloc_contig() call your new function with VM_FREELIST_LOWMEM. (The vm_contig_grow_cache() remains unchanged.) Go back to calling vm_page_free() to release page table pages. For the record, the changes that you made to start using a zone for page table page allocation introduced at least one possible race condition between pmap_remove_pages() and pmap_remove_all(). Specifically, by dropping and reacquiring the page queues and pmap lock when you free a page table page, you allow a pmap_remove_all() call while pmap_remove_pages() is running to leave the variable "npv" in pmap_remove_pages() pointing at a freed pv entry. Regards, Alan From owner-freebsd-mips@FreeBSD.ORG Sat Jun 5 22:40:18 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99CA01065679; Sat, 5 Jun 2010 22:40:18 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2927E8FC17; Sat, 5 Jun 2010 22:40:17 +0000 (UTC) Received: by vws18 with SMTP id 18so881887vws.13 for ; Sat, 05 Jun 2010 15:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/IJy5u+tV2bOk5VSdahDX5aIvtos2GiULnpo8loUYMI=; b=ROCJh+kIWpPypXvqt9Q+6pqhRVn9ox2e696DNt6nhYVe6WdR078KRHv0o2GOSr2hpe 0l/mibjodHxx3BaCnTc145QAPyRh1aYmFZi7WFej+KYtubaPVq6zSCWbN4S4CvwemiYN VkEvq+N3UPsg1rEqDzG6/ykZ7LsPhIRQHspw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AjsKMXx9PM6QrVP8eEegirrHaPlKQaNSqwZZMqfys//iwsa4iiMXwn3CwS6z19pg7d EUCI/3S0fdYf/k6lWX/oMJ8coZGHGPYD4Fw2GfqefJSMbtc+xhry/3Ap7btRtJfZyCNY lFFFpa+fwx6cQdP6nUPPCuytZx1XBGeH1FA5I= MIME-Version: 1.0 Received: by 10.224.105.144 with SMTP id t16mr6908875qao.186.1275777617195; Sat, 05 Jun 2010 15:40:17 -0700 (PDT) Received: by 10.220.189.13 with HTTP; Sat, 5 Jun 2010 15:40:16 -0700 (PDT) In-Reply-To: <4C09345F.9040300@cs.rice.edu> References: <201005271005.o4RA5eVu032269@svn.freebsd.org> <4C058145.3000707@cs.rice.edu> <4C05F9BC.40409@cs.rice.edu> <4C0731A5.7090301@cs.rice.edu> <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> Date: Sun, 6 Jun 2010 04:10:16 +0530 Message-ID: From: "C. Jayachandran" To: Alan Cox Content-Type: multipart/mixed; boundary=00c09f83a1ccaf805d0488501fb1 Cc: "Jayachandran C." , Konstantin Belousov , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips 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: Sat, 05 Jun 2010 22:40:18 -0000 --00c09f83a1ccaf805d0488501fb1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 4, 2010 at 10:44 PM, Alan Cox wrote: > C. Jayachandran wrote: >> >> On Thu, Jun 3, 2010 at 10:33 PM, Alan Cox wrote: >> > > [snip] >> >>> Add a static counter to pmap_ptpgzone_allocf(). =A0When the counter rea= ches >>> some not-too-small prime number, don't call vm_phys_alloc_contig(), >>> instead >>> set "m" to NULL and reset the counter to zero. =A0Setting "m" to NULL >>> should >>> then trigger the vm_contig_grow_cache() call. =A0Make sense? >>> >> >> Is this to move the vm_contig_grow_cache() out of the >> pmap_ptpgzone_allocf() and into the function calling uma_zalloc()? =A0I >> am wondering why the prime number is needed. >> >> Another implementation I had thought about was to have a kernel >> process maintain a pool of direct mapped pages for MIPS. This will be >> woken up if the pool goes below a low water mark - any comments on >> this? >> >> > > Here is how the page table page allocation should be done. =A0It's not mu= ch > harder than the vm_contig_grow_cache() change. > > 1. Look at vm/vm_phys.c, in particular, vm_phys_init(). =A0Create a new > freelist, like =A0 =A0 =A0VM_FREELIST_ISADMA, for the direct-mapped memor= y on > MIPS. =A0Perhaps, call it VM_FREELIST_LOWMEM. =A0The controlling macros s= hould > be defined in mips/include/vmparam.h. > > 2. Trivially refactor vm_phys_alloc_pages(). =A0Specifically, take the bo= dy of > the outer for loop and make it a new function, vm_phys_alloc_freelist(), > =A0that takes the variable "flind" as a parameter. > > 3. Eliminate the UMA zone for page table pages. =A0In place of > vm_phys_alloc_contig() call your new function with VM_FREELIST_LOWMEM. = =A0(The > vm_contig_grow_cache() remains unchanged.) =A0Go back to calling > vm_page_free() to release page table pages. > > For the record, the changes that you made to start using a zone for page > table page allocation introduced at least one possible race condition > between pmap_remove_pages() and pmap_remove_all(). =A0Specifically, by > dropping and reacquiring the page queues and pmap lock when you free a pa= ge > table page, you allow a pmap_remove_all() call while pmap_remove_pages() = is > running to leave the variable "npv" in pmap_remove_pages() pointing at a > freed pv entry. My first attempt is attached, it comes up multiuser but crashes if I stress it a bit (panic: Bad link elm 0xc0078f00 prev->next !=3D elm). Will look at this tomorrow, and see if I can find the cause. In the meantime, it may be worth looking at the patch to see if this is in line with the approach you had suggested. I have tried to use VM_FREELIST_HIGHMEM which is already there, instead of adding VM_FREELIST_LOWMEM. JC. --00c09f83a1ccaf805d0488501fb1 Content-Type: application/octet-stream; name="vm_pagetable_pages.patch" Content-Disposition: attachment; filename="vm_pagetable_pages.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ga30gbg90 SW5kZXg6IHN5cy9taXBzL2luY2x1ZGUvdm1wYXJhbS5oCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9taXBz L2luY2x1ZGUvdm1wYXJhbS5oCShyZXZpc2lvbiAyMDg4NDgpCisrKyBzeXMvbWlwcy9pbmNsdWRl L3ZtcGFyYW0uaAkod29ya2luZyBjb3B5KQpAQCAtMTAzLDggKzEwMyw5IEBACiAjZGVmaW5lCVZN X01BWFVTRVJfQUREUkVTUwkoKHZtX29mZnNldF90KTB4ODAwMDAwMDApCiAjZGVmaW5lCVZNX01B WF9NTUFQX0FERFIJVk1fTUFYVVNFUl9BRERSRVNTCiAKLSNkZWZpbmUJVk1fTUlOX0tFUk5FTF9B RERSRVNTCQkoKHZtX29mZnNldF90KTB4QzAwMDAwMDApCi0jZGVmaW5lCVZNX01BWF9LRVJORUxf QUREUkVTUwkJKCh2bV9vZmZzZXRfdCkweEZGRkZDMDAwKQorI2RlZmluZQlWTV9NSU5fS0VSTkVM X0FERFJFU1MJKCh2bV9vZmZzZXRfdCkweEMwMDAwMDAwKQorI2RlZmluZQlWTV9NQVhfS0VSTkVM X0FERFJFU1MJKCh2bV9vZmZzZXRfdCkweEZGRkZDMDAwKQorI2RlZmluZSBWTV9ISUdITUVNX0FE RFJFU1MJKCh2bV9wYWRkcl90KTB4MjAwMDAwMDApCiAjaWYgMAogI2RlZmluZQlLRVJOQkFTRQkJ KFZNX01JTl9LRVJORUxfQUREUkVTUykKICNlbHNlCkBAIC0xNjgsMTMgKzE2OSwxNSBAQAogI2Rl ZmluZQlWTV9GUkVFUE9PTF9ESVJFQ1QJMQogCiAvKgotICogd2Ugc3VwcG9ydCAxIGZyZWUgbGlz dDoKKyAqIHdlIHN1cHBvcnQgMiBmcmVlIGxpc3RzOgogICoKLSAqCS0gREVGQVVMVCBmb3IgYWxs IHN5c3RlbXMKKyAqCS0gTE9XTUVNIGZvciBEaXJlY3QgbWFwcGVkIChLU0VHMCkgcGFnZXMKKyAq CS0gREVGQVVMVCBmb3IgdGhlIHJlc3QKICAqLwogCi0jZGVmaW5lCVZNX05GUkVFTElTVAkJMQot I2RlZmluZQlWTV9GUkVFTElTVF9ERUZBVUxUCTAKKyNkZWZpbmUJVk1fTkZSRUVMSVNUCQkyCisj ZGVmaW5lCVZNX0ZSRUVMSVNUX0RFRkFVTFQJMQorI2RlZmluZQlWTV9GUkVFTElTVF9ISUdITUVN CTAKIAogLyoKICAqIFRoZSBsYXJnZXN0IGFsbG9jYXRpb24gc2l6ZSBpcyAxTUIuCkluZGV4OiBz eXMvbWlwcy9taXBzL3BtYXAuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbWlwcy9taXBzL3BtYXAuYwko cmV2aXNpb24gMjA4ODQ4KQorKysgc3lzL21pcHMvbWlwcy9wbWFwLmMJKHdvcmtpbmcgY29weSkK QEAgLTE4NCw4ICsxODQsNiBAQAogc3RhdGljIGludCBpbml0X3B0ZV9wcm90KHZtX29mZnNldF90 IHZhLCB2bV9wYWdlX3QgbSwgdm1fcHJvdF90IHByb3QpOwogc3RhdGljIHZvaWQgcG1hcF9UTEJf aW52YWxpZGF0ZV9rZXJuZWwodm1fb2Zmc2V0X3QpOwogc3RhdGljIHZvaWQgcG1hcF9UTEJfdXBk YXRlX2tlcm5lbCh2bV9vZmZzZXRfdCwgcHRfZW50cnlfdCk7Ci1zdGF0aWMgdm1fcGFnZV90IHBt YXBfYWxsb2NfcHRlX3BhZ2UocG1hcF90LCB1bnNpZ25lZCBpbnQsIGludCwgdm1fb2Zmc2V0X3Qg Kik7Ci1zdGF0aWMgdm9pZCBwbWFwX3JlbGVhc2VfcHRlX3BhZ2Uodm1fcGFnZV90KTsKIAogI2lm ZGVmIFNNUAogc3RhdGljIHZvaWQgcG1hcF9pbnZhbGlkYXRlX3BhZ2VfYWN0aW9uKHZvaWQgKmFy Zyk7CkBAIC0xOTMsMTAgKzE5MSw2IEBACiBzdGF0aWMgdm9pZCBwbWFwX3VwZGF0ZV9wYWdlX2Fj dGlvbih2b2lkICphcmcpOwogI2VuZGlmCiAKLXN0YXRpYyB2b2lkIHBtYXBfcHRwZ3pvbmVfZHRv cih2b2lkICptZW0sIGludCBzaXplLCB2b2lkICphcmcpOwotc3RhdGljIHZvaWQgKnBtYXBfcHRw Z3pvbmVfYWxsb2NmKHVtYV96b25lX3QsIGludCwgdV9pbnQ4X3QgKiwgaW50KTsKLXN0YXRpYyB1 bWFfem9uZV90IHB0cGd6b25lOwotCiBzdHJ1Y3QgbG9jYWxfc3lzbWFwcyB7CiAJc3RydWN0IG10 eCBsb2NrOwogCXZtX29mZnNldF90IGJhc2U7CkBAIC01MzUsMTAgKzUyOSw2IEBACiAJcHZfZW50 cnlfbWF4ID0gUE1BUF9TSFBHUEVSUFJPQyAqIG1heHByb2MgKyBjbnQudl9wYWdlX2NvdW50Owog CXB2X2VudHJ5X2hpZ2hfd2F0ZXIgPSA5ICogKHB2X2VudHJ5X21heCAvIDEwKTsKIAl1bWFfem9u ZV9zZXRfb2JqKHB2em9uZSwgJnB2em9uZV9vYmosIHB2X2VudHJ5X21heCk7Ci0KLQlwdHBnem9u ZSA9IHVtYV96Y3JlYXRlKCJQVCBFTlRSWSIsIFBBR0VfU0laRSwgTlVMTCwgcG1hcF9wdHBnem9u ZV9kdG9yLAotCSAgICBOVUxMLCBOVUxMLCBQQUdFX1NJWkUgLSAxLCBVTUFfWk9ORV9OT0ZSRUUg fCBVTUFfWk9ORV9aSU5JVCk7Ci0JdW1hX3pvbmVfc2V0X2FsbG9jZihwdHBnem9uZSwgcG1hcF9w dHBnem9uZV9hbGxvY2YpOwogfQogCiAvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqCkBAIC04ODYsMTEgKzg3Niw3IEBACiAJICogSWYgdGhlIHBhZ2Ug aXMgZmluYWxseSB1bndpcmVkLCBzaW1wbHkgZnJlZSBpdC4KIAkgKi8KIAlhdG9taWNfc3VidHJh Y3RfaW50KCZjbnQudl93aXJlX2NvdW50LCAxKTsKLQlQTUFQX1VOTE9DSyhwbWFwKTsKLQl2bV9w YWdlX3VubG9ja19xdWV1ZXMoKTsKLQlwbWFwX3JlbGVhc2VfcHRlX3BhZ2UobSk7Ci0Jdm1fcGFn ZV9sb2NrX3F1ZXVlcygpOwotCVBNQVBfTE9DSyhwbWFwKTsKKwl2bV9wYWdlX2ZyZWVfemVybyht KTsKIAlyZXR1cm4gKDEpOwogfQogCkBAIC05NDksOTYgKzkzNSw1MCBAQAogCWJ6ZXJvKCZwbWFw LT5wbV9zdGF0cywgc2l6ZW9mIHBtYXAtPnBtX3N0YXRzKTsKIH0KIAotc3RhdGljIHZvaWQKLXBt YXBfcHRwZ3pvbmVfZHRvcih2b2lkICptZW0sIGludCBzaXplLCB2b2lkICphcmcpCitzdGF0aWMg dm1fcGFnZV90CitwbWFwX2FsbG9jX3B0ZV9wYWdlKHBtYXBfdCBwbWFwLCB1bnNpZ25lZCBpbnQg aW5kZXgsIGludCB3YWl0LCB2bV9vZmZzZXRfdCAqdmFwKQogewotI2lmZGVmIElOVkFSSUFOVFMK LQlzdGF0aWMgY2hhciB6ZXJvcGFnZVtQQUdFX1NJWkVdOwotCi0JS0FTU0VSVChzaXplID09IFBB R0VfU0laRSwKLQkJKCJwbWFwX3B0cGd6b25lX2R0b3I6IGludmFsaWQgc2l6ZSAlZCIsIHNpemUp KTsKLQlLQVNTRVJUKGJjbXAobWVtLCB6ZXJvcGFnZSwgUEFHRV9TSVpFKSA9PSAwLAotCQkoInBt YXBfcHRwZ3pvbmVfZHRvcjogZnJlZWluZyBhIG5vbi16ZXJvZWQgcGFnZSIpKTsKLSNlbmRpZgot fQotCi1zdGF0aWMgdm9pZCAqCi1wbWFwX3B0cGd6b25lX2FsbG9jZih1bWFfem9uZV90IHpvbmUs IGludCBieXRlcywgdV9pbnQ4X3QgKmZsYWdzLCBpbnQgd2FpdCkKLXsKLQl2bV9wYWdlX3QgbTsK IAl2bV9wYWRkcl90IHBhZGRyOwotCWludCB0cmllczsKLQkKLQlLQVNTRVJUKGJ5dGVzID09IFBB R0VfU0laRSwKLQkJKCJwbWFwX3B0cGd6b25lX2FsbG9jZjogaW52YWxpZCBhbGxvY2F0aW9uIHNp emUgJWQiLCBieXRlcykpOworCXZtX3BhZ2VfdCBtOworCWludCB0cmllcywgZmxhZ3M7CiAKLQkq ZmxhZ3MgPSBVTUFfU0xBQl9QUklWOwogCXRyaWVzID0gMDsKIHJldHJ5OgotCW0gPSB2bV9waHlz X2FsbG9jX2NvbnRpZygxLCAwLCBNSVBTX0tTRUcwX0xBUkdFU1RfUEhZUywKLQkgICAgUEFHRV9T SVpFLCBQQUdFX1NJWkUpOworCW0gPSB2bV9waHlzX2FsbG9jX2ZyZWVsaXN0X3BhZ2VzKFZNX0ZS RUVMSVNUX0RFRkFVTFQsCisJICAgIFZNX0ZSRUVQT09MX0RFRkFVTFQsIDApOworCWlmICh0cmll cyA+IDApCisJCXByaW50ZigiWyVkXSAlcyB3YWl0ICV4LCBnb3QgJXBcbiIsIHRyaWVzLCBfX2Z1 bmNfXywKKwkJICAgIHdhaXQsIG0pOwogCWlmIChtID09IE5VTEwpIHsKICAgICAgICAgICAgICAg ICBpZiAodHJpZXMgPCAoKHdhaXQgJiBNX05PV0FJVCkgIT0gMCA/IDEgOiAzKSkgewogCQkJdm1f Y29udGlnX2dyb3dfY2FjaGUodHJpZXMsIDAsIE1JUFNfS1NFRzBfTEFSR0VTVF9QSFlTKTsKIAkJ CXRyaWVzKys7CiAJCQlnb3RvIHJldHJ5OwotCQl9IGVsc2UKKwkJfSBlbHNlIHsKKwkJCXByaW50 ZigiWyVkXSAlcyB3YWl0ICV4LCBmYWlsIVxuIiwgdHJpZXMsIF9fZnVuY19fLAorCQkJICAgIHdh aXQpOwogCQkJcmV0dXJuIChOVUxMKTsKKwkJfQogCX0KIAogCXBhZGRyID0gVk1fUEFHRV9UT19Q SFlTKG0pOwotCXJldHVybiAoKHZvaWQgKilNSVBTX1BIWVNfVE9fS1NFRzAocGFkZHIpKTsKLX0J Ci0KLXN0YXRpYyB2bV9wYWdlX3QKLXBtYXBfYWxsb2NfcHRlX3BhZ2UocG1hcF90IHBtYXAsIHVu c2lnbmVkIGludCBpbmRleCwgaW50IHdhaXQsIHZtX29mZnNldF90ICp2YXApCi17Ci0Jdm1fcGFk ZHJfdCBwYWRkcjsKLQl2b2lkICp2YTsKLQl2bV9wYWdlX3QgbTsKLQlpbnQgbG9ja2VkOwotCi0J bG9ja2VkID0gbXR4X293bmVkKCZwbWFwLT5wbV9tdHgpOwotCWlmIChsb2NrZWQpIHsKLQkJbXR4 X2Fzc2VydCgmdm1fcGFnZV9xdWV1ZV9tdHgsIE1BX09XTkVEKTsKLQkJUE1BUF9VTkxPQ0socG1h cCk7Ci0JCXZtX3BhZ2VfdW5sb2NrX3F1ZXVlcygpOwotCX0KLQl2YSA9IHVtYV96YWxsb2MocHRw Z3pvbmUsIHdhaXQpOwotCWlmIChsb2NrZWQpIHsKLQkJdm1fcGFnZV9sb2NrX3F1ZXVlcygpOwot CQlQTUFQX0xPQ0socG1hcCk7Ci0JfQotCWlmICh2YSA9PSBOVUxMKQotCQlyZXR1cm4gKE5VTEwp OwotCi0JcGFkZHIgPSBNSVBTX0tTRUcwX1RPX1BIWVModmEpOwotCW0gPSBQSFlTX1RPX1ZNX1BB R0UocGFkZHIpOwotCQotCWlmICghbG9ja2VkKQotCQl2bV9wYWdlX2xvY2tfcXVldWVzKCk7CiAJ bS0+cGluZGV4ID0gaW5kZXg7CiAJbS0+dmFsaWQgPSBWTV9QQUdFX0JJVFNfQUxMOwogCW0tPndp cmVfY291bnQgPSAxOwotCWlmICghbG9ja2VkKQotCQl2bV9wYWdlX3VubG9ja19xdWV1ZXMoKTsK KwlpZiAobS0+ZmxhZ3MgJiBQR19aRVJPKQorCQl2bV9wYWdlX3plcm9fY291bnQtLTsKKwllbHNl IAorCQlwbWFwX3plcm9fcGFnZShtKTsKKyAJZmxhZ3MgPSBQR19aRVJPIHwgUEdfVU5NQU5BR0VE OworCW0tPmZsYWdzID0gZmxhZ3M7CisJbS0+b2ZsYWdzID0gMDsKKwltLT5hY3RfY291bnQgPSAw OwogCiAJYXRvbWljX2FkZF9pbnQoJmNudC52X3dpcmVfY291bnQsIDEpOwotCSp2YXAgPSAodm1f b2Zmc2V0X3QpdmE7CisJKnZhcCA9IE1JUFNfUEhZU19UT19LU0VHMChwYWRkcik7CiAJcmV0dXJu IChtKTsKIH0KIAotc3RhdGljIHZvaWQKLXBtYXBfcmVsZWFzZV9wdGVfcGFnZSh2bV9wYWdlX3Qg bSkKLXsKLQl2b2lkICp2YTsKLQl2bV9wYWRkcl90IHBhZGRyOwotCi0JcGFkZHIgPSBWTV9QQUdF X1RPX1BIWVMobSk7Ci0JdmEgPSAodm9pZCAqKU1JUFNfUEhZU19UT19LU0VHMChwYWRkcik7Ci0J dW1hX3pmcmVlKHB0cGd6b25lLCB2YSk7Ci19Ci0KIC8qCiAgKiBJbml0aWFsaXplIGEgcHJlYWxs b2NhdGVkIGFuZCB6ZXJvZWQgcG1hcCBzdHJ1Y3R1cmUsCiAgKiBzdWNoIGFzIG9uZSBpbiBhIHZt c3BhY2Ugc3RydWN0dXJlLgpAQCAtMTE5Myw3ICsxMTMzLDcgQEAKIAogCXB0ZHBnLT53aXJlX2Nv dW50LS07CiAJYXRvbWljX3N1YnRyYWN0X2ludCgmY250LnZfd2lyZV9jb3VudCwgMSk7Ci0JcG1h cF9yZWxlYXNlX3B0ZV9wYWdlKHB0ZHBnKTsKKwl2bV9wYWdlX2ZyZWVfemVybyhwdGRwZyk7CiAJ UE1BUF9MT0NLX0RFU1RST1kocG1hcCk7CiB9CiAKSW5kZXg6IHN5cy92bS92bV9waHlzLmMKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gc3lzL3ZtL3ZtX3BoeXMuYwkocmV2aXNpb24gMjA4ODQ4KQorKysgc3lzL3Zt L3ZtX3BoeXMuYwkod29ya2luZyBjb3B5KQpAQCAtMzAxLDEwICszMDEsOCBAQAogdm1fcGFnZV90 CiB2bV9waHlzX2FsbG9jX3BhZ2VzKGludCBwb29sLCBpbnQgb3JkZXIpCiB7Ci0Jc3RydWN0IHZt X2ZyZWVsaXN0ICpmbDsKLQlzdHJ1Y3Qgdm1fZnJlZWxpc3QgKmFsdDsKLQlpbnQgZmxpbmQsIG9p bmQsIHBpbmQ7CiAJdm1fcGFnZV90IG07CisJaW50IGZsaW5kOwogCiAJS0FTU0VSVChwb29sIDwg Vk1fTkZSRUVQT09MLAogCSAgICAoInZtX3BoeXNfYWxsb2NfcGFnZXM6IHBvb2wgJWQgaXMgb3V0 IG9mIHJhbmdlIiwgcG9vbCkpOwpAQCAtMzEyLDM4ICszMTAsNTUgQEAKIAkgICAgKCJ2bV9waHlz X2FsbG9jX3BhZ2VzOiBvcmRlciAlZCBpcyBvdXQgb2YgcmFuZ2UiLCBvcmRlcikpOwogCW10eF9h c3NlcnQoJnZtX3BhZ2VfcXVldWVfZnJlZV9tdHgsIE1BX09XTkVEKTsKIAlmb3IgKGZsaW5kID0g MDsgZmxpbmQgPCB2bV9uZnJlZWxpc3RzOyBmbGluZCsrKSB7Ci0JCWZsID0gdm1fcGh5c19mcmVl X3F1ZXVlc1tmbGluZF1bcG9vbF07Ci0JCWZvciAob2luZCA9IG9yZGVyOyBvaW5kIDwgVk1fTkZS RUVPUkRFUjsgb2luZCsrKSB7Ci0JCQltID0gVEFJTFFfRklSU1QoJmZsW29pbmRdLnBsKTsKKwkJ bSA9IHZtX3BoeXNfYWxsb2NfZnJlZWxpc3RfcGFnZXMoZmxpbmQsIHBvb2wsIG9yZGVyKTsKKwkJ aWYgKG0gIT0gTlVMTCkKKwkJCXJldHVybiBtOworCX0KKwlyZXR1cm4gKE5VTEwpOworfQorCit2 bV9wYWdlX3QKK3ZtX3BoeXNfYWxsb2NfZnJlZWxpc3RfcGFnZXMoaW50IGZsaW5kLCBpbnQgcG9v bCwgaW50IG9yZGVyKQorewkKKwlzdHJ1Y3Qgdm1fZnJlZWxpc3QgKmZsOworCXN0cnVjdCB2bV9m cmVlbGlzdCAqYWx0OworCWludCBvaW5kLCBwaW5kOworCXZtX3BhZ2VfdCBtOworCisJS0FTU0VS VChmbGluZCA8IFZNX05GUkVFTElTVCwKKwkgICAgKCJ2bV9waHlzX2FsbG9jX3BhZ2VzOiBmcmVl bGlzdCAlZCBpcyBvdXQgb2YgcmFuZ2UiLCBmbGluZCkpOworCisJZmwgPSB2bV9waHlzX2ZyZWVf cXVldWVzW2ZsaW5kXVtwb29sXTsKKwlmb3IgKG9pbmQgPSBvcmRlcjsgb2luZCA8IFZNX05GUkVF T1JERVI7IG9pbmQrKykgeworCQltID0gVEFJTFFfRklSU1QoJmZsW29pbmRdLnBsKTsKKwkJaWYg KG0gIT0gTlVMTCkgeworCQkJVEFJTFFfUkVNT1ZFKCZmbFtvaW5kXS5wbCwgbSwgcGFnZXEpOwor CQkJZmxbb2luZF0ubGNudC0tOworCQkJbS0+b3JkZXIgPSBWTV9ORlJFRU9SREVSOworCQkJdm1f cGh5c19zcGxpdF9wYWdlcyhtLCBvaW5kLCBmbCwgb3JkZXIpOworCQkJcmV0dXJuIChtKTsKKwkJ fQorCX0KKworCS8qCisJICogVGhlIGdpdmVuIHBvb2wgd2FzIGVtcHR5LiAgRmluZCB0aGUgbGFy Z2VzdAorCSAqIGNvbnRpZ3VvdXMsIHBvd2VyLW9mLXR3by1zaXplZCBzZXQgb2YgcGFnZXMgaW4g YW55CisJICogcG9vbC4gIFRyYW5zZmVyIHRoZXNlIHBhZ2VzIHRvIHRoZSBnaXZlbiBwb29sLCBh bmQKKwkgKiB1c2UgdGhlbSB0byBzYXRpc2Z5IHRoZSBhbGxvY2F0aW9uLgorCSAqLworCWZvciAo b2luZCA9IFZNX05GUkVFT1JERVIgLSAxOyBvaW5kID49IG9yZGVyOyBvaW5kLS0pIHsKKwkJZm9y IChwaW5kID0gMDsgcGluZCA8IFZNX05GUkVFUE9PTDsgcGluZCsrKSB7CisJCQlhbHQgPSB2bV9w aHlzX2ZyZWVfcXVldWVzW2ZsaW5kXVtwaW5kXTsKKwkJCW0gPSBUQUlMUV9GSVJTVCgmYWx0W29p bmRdLnBsKTsKIAkJCWlmIChtICE9IE5VTEwpIHsKLQkJCQlUQUlMUV9SRU1PVkUoJmZsW29pbmRd LnBsLCBtLCBwYWdlcSk7Ci0JCQkJZmxbb2luZF0ubGNudC0tOworCQkJCVRBSUxRX1JFTU9WRSgm YWx0W29pbmRdLnBsLCBtLCBwYWdlcSk7CisJCQkJYWx0W29pbmRdLmxjbnQtLTsKIAkJCQltLT5v cmRlciA9IFZNX05GUkVFT1JERVI7CisJCQkJdm1fcGh5c19zZXRfcG9vbChwb29sLCBtLCBvaW5k KTsKIAkJCQl2bV9waHlzX3NwbGl0X3BhZ2VzKG0sIG9pbmQsIGZsLCBvcmRlcik7CiAJCQkJcmV0 dXJuIChtKTsKIAkJCX0KIAkJfQotCi0JCS8qCi0JCSAqIFRoZSBnaXZlbiBwb29sIHdhcyBlbXB0 eS4gIEZpbmQgdGhlIGxhcmdlc3QKLQkJICogY29udGlndW91cywgcG93ZXItb2YtdHdvLXNpemVk IHNldCBvZiBwYWdlcyBpbiBhbnkKLQkJICogcG9vbC4gIFRyYW5zZmVyIHRoZXNlIHBhZ2VzIHRv IHRoZSBnaXZlbiBwb29sLCBhbmQKLQkJICogdXNlIHRoZW0gdG8gc2F0aXNmeSB0aGUgYWxsb2Nh dGlvbi4KLQkJICovCi0JCWZvciAob2luZCA9IFZNX05GUkVFT1JERVIgLSAxOyBvaW5kID49IG9y ZGVyOyBvaW5kLS0pIHsKLQkJCWZvciAocGluZCA9IDA7IHBpbmQgPCBWTV9ORlJFRVBPT0w7IHBp bmQrKykgewotCQkJCWFsdCA9IHZtX3BoeXNfZnJlZV9xdWV1ZXNbZmxpbmRdW3BpbmRdOwotCQkJ CW0gPSBUQUlMUV9GSVJTVCgmYWx0W29pbmRdLnBsKTsKLQkJCQlpZiAobSAhPSBOVUxMKSB7Ci0J CQkJCVRBSUxRX1JFTU9WRSgmYWx0W29pbmRdLnBsLCBtLCBwYWdlcSk7Ci0JCQkJCWFsdFtvaW5k XS5sY250LS07Ci0JCQkJCW0tPm9yZGVyID0gVk1fTkZSRUVPUkRFUjsKLQkJCQkJdm1fcGh5c19z ZXRfcG9vbChwb29sLCBtLCBvaW5kKTsKLQkJCQkJdm1fcGh5c19zcGxpdF9wYWdlcyhtLCBvaW5k LCBmbCwgb3JkZXIpOwotCQkJCQlyZXR1cm4gKG0pOwotCQkJCX0KLQkJCX0KLQkJfQogCX0KIAly ZXR1cm4gKE5VTEwpOwogfQpJbmRleDogc3lzL3ZtL3ZtX3BoeXMuaAo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz eXMvdm0vdm1fcGh5cy5oCShyZXZpc2lvbiAyMDg4NDgpCisrKyBzeXMvdm0vdm1fcGh5cy5oCSh3 b3JraW5nIGNvcHkpCkBAIC00NCw2ICs0NCw3IEBACiB2bV9wYWdlX3Qgdm1fcGh5c19hbGxvY19j b250aWcodW5zaWduZWQgbG9uZyBucGFnZXMsCiAgICAgdm1fcGFkZHJfdCBsb3csIHZtX3BhZGRy X3QgaGlnaCwKICAgICB1bnNpZ25lZCBsb25nIGFsaWdubWVudCwgdW5zaWduZWQgbG9uZyBib3Vu ZGFyeSk7Cit2bV9wYWdlX3Qgdm1fcGh5c19hbGxvY19mcmVlbGlzdF9wYWdlcyhpbnQgZmxpbmQs IGludCBwb29sLCBpbnQgb3JkZXIpOwogdm1fcGFnZV90IHZtX3BoeXNfYWxsb2NfcGFnZXMoaW50 IHBvb2wsIGludCBvcmRlcik7CiB2bV9wYWRkcl90IHZtX3BoeXNfYm9vdHN0cmFwX2FsbG9jKHZt X3NpemVfdCBzaXplLCB1bnNpZ25lZCBsb25nIGFsaWdubWVudCk7CiB2b2lkIHZtX3BoeXNfZnJl ZV9wYWdlcyh2bV9wYWdlX3QgbSwgaW50IG9yZGVyKTsK --00c09f83a1ccaf805d0488501fb1--