From: Richard Henderson <richard.henderson@linaro.org>
To: Bruno Piazera Larsen <bruno.larsen@eldorado.org.br>,
qemu-devel@nongnu.org
Cc: farosas@linux.ibm.com, luis.pires@eldorado.org.br,
Greg Kurz <groug@kaod.org>,
lucas.araujo@eldorado.org.br, fernando.valle@eldorado.org.br,
qemu-ppc@nongnu.org, matheus.ferst@eldorado.org.br,
david@gibson.dropbear.id.au
Subject: Re: [RFC PATCH] target/ppc: fix address translation bug for hash table mmus
Date: Tue, 8 Jun 2021 08:35:03 -0700 [thread overview]
Message-ID: <cd077bef-c6a5-8041-e0e4-2ac554b96735@linaro.org> (raw)
In-Reply-To: <b5834a1f-afaa-a36a-11d6-35a197ad74bc@eldorado.org.br>
On 6/8/21 7:39 AM, Bruno Piazera Larsen wrote:
>> That's odd. We already have more arguments than the number of argument
>> registers... A 5x slowdown is distinctly odd.
> I did some more digging and the problem is not with ppc_radix64_check_prot, the
> problem is ppc_radix64_xlate, which currently has 7 arguments and we're
> increasing to 8. 7 feels like the correct number, but I couldn't find docs
> supporting it, so I could be wrong.
According to tcg/ppc/tcg-target.c.inc, there are 8 argument registers for ppc
hosts. But now I see you didn't actually say on which host you observed the
problem... It's 6 argument registers for x86_64 host.
> That means we'd have to define radix_ctx_t (or however we call it) in
> radix64.h, setup the struct on ppc_xlate, then pass it to ppc_radix64_xlate.
Well, if you're going to change the xlate interface, you want to do that across
all of them. So, not call it radix_ctx_t.
> From looking at the code, it seems the most useful bits to put in the struct
> are: eaddr, g_addr, h_addr, {h,g}_prot, {g,h}_page_size, mmu_idx and
> guest_visible. They all seem reasonable to me, but I might be missing something
> again.
I don't think h/g should be in this struct. I think h/g should use different
struct instances, because they are different accesses.
r~
next prev parent reply other threads:[~2021-06-08 15:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-02 19:18 [RFC PATCH] target/ppc: fix address translation bug for hash table mmus Bruno Larsen (billionai)
2021-06-02 19:26 ` Richard Henderson
2021-06-02 19:58 ` Bruno Piazera Larsen
2021-06-02 22:19 ` Richard Henderson
2021-06-07 19:29 ` Bruno Piazera Larsen
2021-06-07 21:06 ` Richard Henderson
2021-06-08 14:39 ` Bruno Piazera Larsen
2021-06-08 15:35 ` Richard Henderson [this message]
2021-06-08 16:37 ` Bruno Piazera Larsen
2021-06-08 18:39 ` Bruno Piazera Larsen
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=cd077bef-c6a5-8041-e0e4-2ac554b96735@linaro.org \
--to=richard.henderson@linaro.org \
--cc=bruno.larsen@eldorado.org.br \
--cc=david@gibson.dropbear.id.au \
--cc=farosas@linux.ibm.com \
--cc=fernando.valle@eldorado.org.br \
--cc=groug@kaod.org \
--cc=lucas.araujo@eldorado.org.br \
--cc=luis.pires@eldorado.org.br \
--cc=matheus.ferst@eldorado.org.br \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@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.