From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvTme-0006ht-FH for qemu-devel@nongnu.org; Thu, 21 May 2015 12:57:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvTmb-0000kk-Q1 for qemu-devel@nongnu.org; Thu, 21 May 2015 12:57:24 -0400 Received: from mail-qk0-x22e.google.com ([2607:f8b0:400d:c09::22e]:35364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvTmb-0000jq-Lu for qemu-devel@nongnu.org; Thu, 21 May 2015 12:57:21 -0400 Received: by qkdn188 with SMTP id n188so55195434qkd.2 for ; Thu, 21 May 2015 09:57:21 -0700 (PDT) Sender: Richard Henderson Message-ID: <555E0E6C.9050003@twiddle.net> Date: Thu, 21 May 2015 09:57:16 -0700 From: Richard Henderson MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] tcg & sparc mmu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel On 05/21/2015 02:06 AM, Artyom Tarasenko wrote: > Hi Richard, > > looking at target-sparc/cpu.h and target-sparc/ldst_helper.c I have an > impression, that 2 mmu modes are not enough for sparc (32) machines: > they have 4 types of accesses: the combination of user/privileged and > data/code. Data vs code doesn't need separate mmu modes. Just different methods of access. That said, sparc64 has 6 modes... > Also afaics cpu_ldu{b,w,l,q}_code uses the currently selected MMU mode. > if this is correct, the current implementation of ASI 0x9 ( /* > Supervisor code access */) in target-sparc/ldst_helper.c is imprecise, > it would use the current mmu translation which is not necessarily > privileged. On sparc32, we are guaranteed to be privileged, and there's a check for that in the translator. #ifndef TARGET_SPARC64 if (IS_IMM) goto illegal_insn; if (!supervisor(dc)) goto priv_insn; #endif On sparc64, there are two modes higher than kernel: nucleus and hypervisor. For these, the access is being done with the wrong mode. Further, there's no check in helper_ld_asi for permissions. The double-bug means there isn't currently a hole in user accessing supervisor code, but to fix one bug requires that we fix the other. > Also I wonder how to implement a user_code access (ASI 0x8). Do I have > to add more NB_MMU_MODES? No, you just need to use the right function. In this case helper_ld*_cmmu, which includes an mmu_idx parameter, performs a read with "code" or execute permissions rather than "data" or read permissions. This whole area could stand to be totally re-written, btw. Especially to support the sparcv9 immediate asi with simple loads from non-default modes, the byte-swapping asis, and the fpu data movement asis. r~