qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Filippov <jcmvbkbc@gmail.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel <qemu-devel@nongnu.org>,
	Patch Tracking <patches@linaro.org>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [RFC PATCH] xtensa: Avoid calling get_page_addr_code() from helper function
Date: Sat, 30 Jun 2018 11:55:28 -0700	[thread overview]
Message-ID: <CAMo8BfLsASNPVKix0U2sP55omcbcVUQJen4kpcoLjH=86PdPgA@mail.gmail.com> (raw)
In-Reply-To: <20180622135823.32421-1-peter.maydell@linaro.org>

On Fri, Jun 22, 2018 at 6:58 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> The xtensa frontend calls get_page_addr_code() from its
> itlb_hit_test helper function. This function is really part
> of the TCG core's internals, and calling it from a target
> helper makes it awkward to make changes to that core code.
> It also means that we don't pass the correct retaddr to
> tlb_fill(), so we won't correctly handle the case where
> an exception is generated.
>
> The helper is used for the instructions IHI, IHU and IPFL.
>
> Change it to call cpu_ldb_code_ra() instead.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> This retains the current behaviour that all these insns
> may cause exceptions both for MMU permissions checks
> failures and also for "resulting physaddr doesn't point
> at memory".
>
> My reading of the ISA manual is that this isn't strictly
> correct for IHI and IHU, which ought to only cause MMU
> exceptions but not actually do a memory access. If we
> wanted to fix that, the right thing would be to split
> them into their own helper function, which could then
> just do a tlb_fill().
>
> Tagged as RFC because I don't have any xtensa test images.
>
> My motivation here is that at some point I'd like us to
> support execution from arbitrary MMIO/small MPU regions/etc,
> for which purpose get_page_addr_code() will change to return
> -1 to mean "this isn't RAM, load a single insn into a
> throwaway TB and execute it"...

I'm taking this patch, thank you. This test is not worse than
what is done for the data cache. And if it causes problem it'd
be easy to spot, because an exception code for accessing
nonexistent physical memory is very unusual.

-- 
Thanks.
-- Max

      parent reply	other threads:[~2018-06-30 18:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-22 13:58 [Qemu-devel] [RFC PATCH] xtensa: Avoid calling get_page_addr_code() from helper function Peter Maydell
2018-06-30 17:32 ` Richard Henderson
2018-06-30 18:22   ` Max Filippov
2018-06-30 18:55 ` Max Filippov [this message]

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='CAMo8BfLsASNPVKix0U2sP55omcbcVUQJen4kpcoLjH=86PdPgA@mail.gmail.com' \
    --to=jcmvbkbc@gmail.com \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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).