All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Richard Henderson <rth@twiddle.net>, qemu-devel@nongnu.org
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [Qemu-devel] TCG problem with cpu_{st,ld}x_data ?
Date: Mon, 25 Jul 2016 15:15:36 +1000	[thread overview]
Message-ID: <1469423736.5978.13.camel@kernel.crashing.org> (raw)
In-Reply-To: <441c89df-0830-ab0c-6298-89374b1cbe9d@twiddle.net>

On Mon, 2016-07-25 at 06:04 +0530, Richard Henderson wrote:
> I noticed a related problem recently, while working on the cmpxchg patch set.
> 
> In my opinion, we should (1) merge GETRA and GETPC so there's no confusion 
> between the two, (2) push all adjustment down to the final moment before use, 
> perhaps in cpu_restore_state.
> 
> Thus a null value would be properly retained until checked, and one can easily 
> call the memory helper functions without confusion.

Ok, after a bit more scrubbing of the code I think I understand what you
mean.

Now assuming we fix that, there is still a problem if the target code, such
as the PPC code, calls a helper that might cause a fault without first
updating the PC in the env, right ? IE. On powerpc for example, that means
that any instruction using a helper that might potentially do loads or stores
needs to first call gen_update_nip().

(The same way we seem to do before generating other exceptions such as traps,
well provided we do it correctly everywhere, I need to double check).

Either that, or change the helpers to capture the PC using GETPC/GETRA from
the first level of helper function (so as to ensure the return address is
correct).

Am I right ?

IE. Even if we fix the 0 vs. -2 problem, I still need this patch:

--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -6916,6 +6916,7 @@ static void gen_lve##name(DisasContext *ctx)                            \
         if (size > 1) {                                                 \
             tcg_gen_andi_tl(EA, EA, ~(size - 1));                       \
         }                                                               \
+        gen_update_nip(ctx, ctx->nip - 4);                              \
         rs = gen_avr_ptr(rS(ctx->opcode));                              \
         gen_helper_lve##name(cpu_env, rs, EA);                          \
         tcg_temp_free(EA);                                              \
@@ -6937,6 +6938,7 @@ static void gen_stve##name(DisasContext *ctx)                           \
         if (size > 1) {                                                 \
             tcg_gen_andi_tl(EA, EA, ~(size - 1));                       \
         }                                                               \
+        gen_update_nip(ctx, ctx->nip - 4);                              \
         rs = gen_avr_ptr(rS(ctx->opcode));                              \
         gen_helper_stve##name(cpu_env, rs, EA);                         \
         tcg_temp_free(EA);                                              \

(And possibly others I haven't yet audited)

Cheers,
Ben.

  reply	other threads:[~2016-07-25  5:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-24 12:42 [Qemu-devel] TCG problem with cpu_{st,ld}x_data ? Benjamin Herrenschmidt
2016-07-24 12:51 ` Benjamin Herrenschmidt
2016-07-24 12:52   ` Benjamin Herrenschmidt
2016-07-25  0:36     ` Richard Henderson
2016-07-25  0:46       ` Benjamin Herrenschmidt
2016-07-25  0:51         ` Benjamin Herrenschmidt
2016-07-25 14:00           ` Richard Henderson
2016-07-25 21:42             ` Benjamin Herrenschmidt
2016-07-25 22:19               ` Peter Maydell
2016-07-25 22:42                 ` Benjamin Herrenschmidt
2016-07-25 23:22                   ` Benjamin Herrenschmidt
2016-07-25  0:34 ` Richard Henderson
2016-07-25  5:15   ` Benjamin Herrenschmidt [this message]
2016-07-25 14:12     ` Richard Henderson
2016-07-25 21:46       ` Benjamin Herrenschmidt

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=1469423736.5978.13.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=borntraeger@de.ibm.com \
    --cc=pbonzini@redhat.com \
    --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 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.