From owner-freebsd-mips@FreeBSD.ORG Thu Aug 12 07:35:33 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 97763106566C; Thu, 12 Aug 2010 07:35:33 +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 39E0D8FC14; Thu, 12 Aug 2010 07:35:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o7C7WGMd099438; Thu, 12 Aug 2010 01:32:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 12 Aug 2010 01:32:46 -0600 (MDT) Message-Id: <20100812.013246.575506241299663760.imp@bsdimp.com> To: c.jayachandran@gmail.com From: "M. Warner Losh" In-Reply-To: References: <20100812.010121.123339447223515204.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: jmallett@FreeBSD.org, freebsd-mips@FreeBSD.org Subject: Re: SMP support for n64 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, 12 Aug 2010 07:35:33 -0000 In message: "Jayachandran C." writes: : On Thu, Aug 12, 2010 at 12:31 PM, M. Warner Losh wro= te: : > In message: : > =A0 =A0 =A0 =A0 =A0 =A0"Jayachandran C." = writes: : > : I've attached a patch that enables SMP support for N64 builds (I = can : > : get XLR come up multi-user with 32 cpus with this). : > : : > : I ended up making KX bit in status register set when you are in : > : userspace, since the PCPU area is now mapped in XKSEG. =A0The PCP= U area : > : needs to be accessed in =A0I have reverted the earlier change tha= t : > : enabled KX on kernel entry from userspace since that is no longer= : > : needed. : > : : > : Please let me know your comments. : > : > If I understand correctly, and I'm sure the pedants will tell me : > otherwise, the KX bit means that a legal reference to a kernel addr= ess : > is made, it will be interpreted as a 64-bit address when KX is set,= : > and a 32-bit address when it is clear. : > : > It does not grant any additional access to the kernel memory that : > isn't already granted by the TLB entries, correct? =A0It doesn't gr= ant : > access to the kernel memory, correct? : = : My understanding is this, but I was not able to find any reference : that says exactly that (so was not sure if some MIPS implementations : have issues here). Yes. I think that the references I cited below reaffirm this. Kernel addresses can only be accessed when KSU =3D=3D 0. : > But I'm a little confused. =A0I'm reading through section 4.5 of th= e : > Privileged Resources Architecture document from mips : > (MD00091-2B-MIPS74PRA-AFP-02.50.pdf) and table 4-1 suggests that : > running with it in user mode won't change what can be accessed. =A0= So : > why would it need to be turned on at all in user mode? =A0Rather th= an : > the xtlb routine being called for the refill for a kernel address, = it : > will fault instead. : > : > Or is this an optimization for the xtlb handler which needs to get = to : > pcpu data? : = : Yes, otherwise I need to add code to the XTLB handler to enable KX : (which will involve read and write to status register and the related= : hazards). Enabling KX everywhere, including userspace avoids this. Ah, that makes perfect sense. Based on that, I can't see any reason to hold this back. Warner