All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Henderson <rth@twiddle.net>
To: Artyom Tarasenko <atar4qemu@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] tcg & sparc mmu
Date: Thu, 21 May 2015 09:57:16 -0700	[thread overview]
Message-ID: <555E0E6C.9050003@twiddle.net> (raw)
In-Reply-To: <CACXAS8BYkHnF2dTU34133miV1LZ-jfn2oaCJh1hb9Y94O5XgYA@mail.gmail.com>

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~

           reply	other threads:[~2015-05-21 16:57 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <CACXAS8BYkHnF2dTU34133miV1LZ-jfn2oaCJh1hb9Y94O5XgYA@mail.gmail.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=555E0E6C.9050003@twiddle.net \
    --to=rth@twiddle.net \
    --cc=atar4qemu@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.