From: Blue Swirl <blauwirbel@gmail.com>
To: Aurelien Jarno <aurelien@aurel32.net>
Cc: Peter Maydell <peter.maydell@linaro.org>,
patches@linaro.org, Paul Brook <paul@codesourcery.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] target-arm: Minimal implementation of performance counters
Date: Sun, 15 May 2011 01:01:40 +0300 [thread overview]
Message-ID: <BANLkTinpg4O0nMEkbhKF12LmjQ5Y49ORZA@mail.gmail.com> (raw)
In-Reply-To: <20110514213247.GB13600@volta.aurel32.net>
On Sun, May 15, 2011 at 12:32 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On Fri, May 06, 2011 at 03:32:27PM +0100, Peter Maydell wrote:
>> On 26 April 2011 11:23, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> > On Mon, Apr 25, 2011 at 11:35:54PM +0100, Peter Maydell wrote:
>> >> On 25 April 2011 23:31, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> >> > On Mon, Apr 25, 2011 at 10:59:52PM +0100, Peter Maydell wrote:
>> >> >> On 25 April 2011 22:09, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> >> >> > Instead of having this complex test for all cp15 access, but only for
>> >> >> > catching a few access to performance registers, wouldn't it make more
>> >> >> > sense to have this test and an exception triggering directly in
>> >> >> > helper.c?
>> >> >>
>> >> >> That was what my first design did, but in discussions on IRC
>> >> >> with Paul Brook he basically said that you can't generate an
>> >> >> exception in the helper routine, you have to either generate
>> >> >> runtime code to do the test or throw away the TBs. Unfortunately
>> >> >> I forget the exact rationale, so I've cc'd Paul to remind me :-)
>> >> >
>> >> > This is something strange, plenty of targets are raising exceptions from
>> >> > helpers without any problem.
>> >>
>> >> You'd at minimum need to move the cp15 helper functions to a different
>> >> file, they're currently in helper.c which doesn't get compiled
>> >> with access to the global 'env' register.
>>
>> > I agree, but it's something that has to be done sooner or later anyway.
>>
>> I just spoke with Paul on IRC about this. In summary:
>> * for a helper to cause an exception then it has (a) to make sure CPU
>> state (pc, condflags) is sync'd before the call to the helper and (b)
>> the helper has to be in a file with access to global env, because it
>> needs to call cpu_loop_exit()
>
> I don't think (a) is true. It is possible to use the same way as for
> load/store operations, that is call cpu_restore_state() before calling
> cpu_loop_exit().
>
>> * (a) is a bit fragile because it's easy to forget and if TCG gets
>> cleverer things might break in a hard-to-track down way
>> * (b) is bad because it increases the set of helper functions accessing
>> global env
>> * and therefore helpers which throw exceptions are a bad idea
>>
>> For rationale for/arguing about (b) see the comment on this patch:
>> http://patchwork.ozlabs.org/patch/94384/
>>
>
> If you don't really like having env as a fixed host registers (recent
> patch series from Blue Swirl seems to want to get rid of this), it is
> possible to pass env as an argument of the helper to do that.
>
> What ever solution is used, we need env for the load/store functions,
Currently this is true, but actually qemu_ld/st only need a pointer to
the TLB. If the address is a constant, some of the TLB calculations
could be performed at translation time. This would need a very
different approach to qemu_ld/st than current one.
next prev parent reply other threads:[~2011-05-14 22:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-21 16:01 [Qemu-devel] [PATCH] target-arm: Minimal implementation of performance counters Peter Maydell
2011-04-22 7:23 ` Brad Hards
2011-04-22 9:48 ` Peter Maydell
2011-04-22 10:32 ` Brad Hards
2011-04-25 21:09 ` Aurelien Jarno
2011-04-25 21:59 ` Peter Maydell
2011-04-25 22:31 ` Aurelien Jarno
2011-04-25 22:35 ` Peter Maydell
2011-04-26 10:23 ` Aurelien Jarno
2011-05-06 14:32 ` Peter Maydell
2011-05-14 21:32 ` Aurelien Jarno
2011-05-14 22:01 ` Blue Swirl [this message]
2011-05-14 22:10 ` Aurelien Jarno
2011-05-16 9:59 ` Peter Maydell
2011-05-16 17:29 ` Aurelien Jarno
2011-05-16 17:51 ` Peter Maydell
2011-06-15 17:39 ` Peter Maydell
2011-05-16 16:10 ` Paul Brook
2011-05-16 16:37 ` Peter Maydell
2011-05-16 17:29 ` Aurelien Jarno
2011-05-16 17:47 ` Peter Maydell
2011-05-16 18:06 ` Aurelien Jarno
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=BANLkTinpg4O0nMEkbhKF12LmjQ5Y49ORZA@mail.gmail.com \
--to=blauwirbel@gmail.com \
--cc=aurelien@aurel32.net \
--cc=patches@linaro.org \
--cc=paul@codesourcery.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@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 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).