From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LeDou-000129-Sb for qemu-devel@nongnu.org; Mon, 02 Mar 2009 14:28:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LeDot-00011W-Bo for qemu-devel@nongnu.org; Mon, 02 Mar 2009 14:28:56 -0500 Received: from [199.232.76.173] (port=46150 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LeDot-00011C-5d for qemu-devel@nongnu.org; Mon, 02 Mar 2009 14:28:55 -0500 Received: from mail-fx0-f175.google.com ([209.85.220.175]:62363) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LeDos-0004C0-NV for qemu-devel@nongnu.org; Mon, 02 Mar 2009 14:28:55 -0500 Received: by fxm23 with SMTP id 23so1973425fxm.34 for ; Mon, 02 Mar 2009 11:28:52 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1236013674-28082-1-git-send-email-agraf@suse.de> <1236013674-28082-2-git-send-email-agraf@suse.de> <1236013674-28082-3-git-send-email-agraf@suse.de> Date: Mon, 2 Mar 2009 21:28:52 +0200 Message-ID: From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 2/3] PPC64: Implement slbmte Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org On 3/2/09, Alexander Graf wrote: > > On 02.03.2009, at 19:58, Blue Swirl wrote: > > > > On 3/2/09, Alexander Graf wrote: > > > > > In order to modify SLB entries on recent PPC64 machines, the slbmte > > > instruction is used. > > > > > > This patch implements the slbmte instruction and makes the "bridge" > > > mode code use the slb set functions, so we can move the SLB into > > > the CPU struct later. > > > > > > This is required for Linux to run on PPC64. > > > > > > Signed-off-by: Alexander Graf > > > > > > > > > > void ppc_store_sr (CPUPPCState *env, int srnum, target_ulong value) > > > { > > > LOG_MMU("%s: reg=%d " ADDRX " " ADDRX "\n", > > > __func__, srnum, value, env->sr[srnum]); > > > - if (env->sr[srnum] != value) { > > > + if (env->mmu_model & POWERPC_MMU_64) { > > > > > > > > > > target_ulong helper_load_sr (target_ulong sr_num) > > > { > > > + if (env->mmu_model & POWERPC_MMU_64) > > > + return ppc_load_sr(env, sr_num); > > > return env->sr[sr_num]; > > > } > > > > > > > It would be faster to move the MMU model checks to translation time. > > > > The problem is that we don't know which -cpu the user will give us when we > run qemu-system-ppc64. > Of course we could just make qemu-system-ppc64 not take any non-64 bit > CPUs, if nobody totally disagrees. env could contain a pointer to (static const) structure describing the CPU features. This pointer would be copied to corresponding DisasContext feature pointer, to be used by the translation functions. See for example target-sparc: translate.c (CHECK_IU_FEATURE macro) and helper.c for CPU definitions. IIRC MIPS or ARM have even nicer macros.