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: Tue, 26 Jul 2016 07:42:03 +1000 [thread overview]
Message-ID: <1469482923.5978.54.camel@kernel.crashing.org> (raw)
In-Reply-To: <b15faa79-7481-5265-f145-e2254d4c7dfa@twiddle.net>
On Mon, 2016-07-25 at 19:30 +0530, Richard Henderson wrote:
> > Or can they also be called outside of that context ?
>
> No, not without a valid return address.
>
> E.g. it's not valid to have one helper call another, and for the second helper
> use GETPC. For this, typically, one must factor out a common function which
> accepts a "retaddr" argument, which the callers must fill in with GETPC.
Right, I've figured that out. I notice that the cpu_ldl_code() are
sprinkled in parts that are "chancy".
For example we have one in powerpc_excp() to read the faulting
instruction, though that *should* never fail it's till not great.
I haven't completely figured out what code path instruction translation
faults take, I assume we longjmp out of the translation loop the same
was as we do out of the execution loop ?
Note: I've started cleaning that on ppc (but not fixing the -2 bug yet)
in there: very much a work in progress but I'd be happy to have initial
feedback (ignore patch 1 about MOL OSI, it's unrelated):
https://github.com/ozbenh/qemu/commits/wip
Cheers,
Ben.
next prev parent reply other threads:[~2016-07-25 21:42 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 [this message]
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
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=1469482923.5978.54.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.