qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Wu, Fei" <fei2.wu@intel.com>
To: Richard Henderson <richard.henderson@linaro.org>,
	LIU Zhiwei <zhiwei_liu@linux.alibaba.com>,
	<qemu-riscv@nongnu.org>, <qemu-devel@nongnu.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	Alistair Francis <alistair.francis@wdc.com>,
	Bin Meng <bin.meng@windriver.com>,
	Weiwei Li <liweiwei@iscas.ac.cn>,
	Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
	Christoph Muellner <christoph.muellner@vrull.eu>
Subject: Re: [PATCH v4 1/2] target/riscv: separate priv from mmu_idx
Date: Fri, 24 Mar 2023 11:01:27 +0800	[thread overview]
Message-ID: <419d1abd-9664-3de7-af0c-97bbfa1d099b@intel.com> (raw)
In-Reply-To: <4951f368-400f-9dac-524a-d3264f0b96ab@linaro.org>

On 3/24/2023 10:37 AM, Richard Henderson wrote:
> On 3/23/23 18:20, Wu, Fei wrote:
>> I lack some background here, why should tb_flags be preferred if env has
>> the same info? Then for reading from tb_flags, we need to add it to
>> tb_flags first.
> 
> We read from tb_flags in translate because that proves we've added the
> data to tb_flags for the TB hash.  It avoids errors like the one for
> vstart.
> 
Got it.

>> Correct me if I'm wrong. The only strong reason we add some flag to
>> tb_flags is that it causes codegen generate different code because of
>> this flag change, and it looks like priv is not one of them, neither is
>> mmu_idx, the generated code does use mmu_idx, but no different code
>> generated for it.
> 
> PRIV definitely affects the generated code: for a supervisor
> instruction, such as REQUIRE_PRIV_MS, we emit gen_exception_illegal() if
> PRIV == U.
> 
You are right, another one is just mentioned semihosting_enabled() in
trans_ebreak.

> MMU_IDX definitely affects the generated code, because that immediate
> value makes its way into the memory offsets in the softmmu lookup
> sequence.  Have a look at the output of -d op_opt,out_asm.
> 

Yes, I think you mean the fast path for softmmu lookup.

>> I think here we have some other reasons to include more, e.g. reference
>> env can be error-prone in some way. So there are minimal flags must be
>> in tb_flags, but we think it's better to add more?
> 
> We add the ones required for efficiency of execution.
> 
> We had not originally added PRIV, because the (original) few
> instructions in trans_privileged.c.inc all call helpers anyway, so it
> was easy enough to check PRIV in the helper.
> 
> Since then more uses have grown.  We *could* turn those into helper
> functions as well, but every other guest arch includes the privilege
> level in tb_flags, and it seems natural to do so.  Only if you
> completely run out of bits would I consider working hard to eliminate
> that one.
> 
It makes sense. This is very informative, I appreciate it very much.

Thanks,
Fei.

> 
> r~



  reply	other threads:[~2023-03-24  6:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23  2:44 [PATCH v4 0/2] target/riscv: reduce MSTATUS_SUM overhead Fei Wu
2023-03-23  2:44 ` [PATCH v4 1/2] target/riscv: separate priv from mmu_idx Fei Wu
2023-03-23  5:37   ` LIU Zhiwei
2023-03-23  6:00     ` Wu, Fei
2023-03-23  6:25       ` Wu, Fei
2023-03-23  6:59       ` LIU Zhiwei
2023-03-23 13:18         ` Wu, Fei
2023-03-23 16:07       ` Richard Henderson
2023-03-24  1:20         ` Wu, Fei
2023-03-24  2:37           ` Richard Henderson
2023-03-24  3:01             ` Wu, Fei [this message]
2023-03-23 15:53   ` Richard Henderson
2023-03-24  1:02     ` Wu, Fei
2023-03-24  1:22       ` Wu, Fei
2023-03-24 12:31       ` Wu, Fei
2023-03-23  2:44 ` [PATCH v4 2/2] target/riscv: reduce overhead of MSTATUS_SUM change Fei Wu

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=419d1abd-9664-3de7-af0c-97bbfa1d099b@intel.com \
    --to=fei2.wu@intel.com \
    --cc=alistair.francis@wdc.com \
    --cc=bin.meng@windriver.com \
    --cc=christoph.muellner@vrull.eu \
    --cc=dbarboza@ventanamicro.com \
    --cc=liweiwei@iscas.ac.cn \
    --cc=palmer@dabbelt.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-riscv@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=zhiwei_liu@linux.alibaba.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).