From owner-freebsd-mips@FreeBSD.ORG Thu Aug 12 07:05:37 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 CD66E106566B; Thu, 12 Aug 2010 07:05:37 +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 8C4068FC16; Thu, 12 Aug 2010 07:05:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o7C70o0e099207; Thu, 12 Aug 2010 01:00:50 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 12 Aug 2010 01:01:21 -0600 (MDT) Message-Id: <20100812.010121.123339447223515204.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=us-ascii Content-Transfer-Encoding: 7bit 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:05:37 -0000 In message: "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. The PCPU area : needs to be accessed in I have reverted the earlier change that : 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 address 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? It doesn't grant access to the kernel memory, correct? But I'm a little confused. I'm reading through section 4.5 of the 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. So why would it need to be turned on at all in user mode? Rather than 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? Warner