From: Jan Kiszka <jan.kiszka@web.de>
To: Stefan Weil <weil@mail.berlios.de>
Cc: qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>,
Jun Koi <junkoi2004@gmail.com>
Subject: Re: [Qemu-devel] Re: [PATCH] flush TB on singlestep command
Date: Thu, 22 Apr 2010 09:02:40 +0200 [thread overview]
Message-ID: <4BCFF490.6060407@web.de> (raw)
In-Reply-To: <4BCF4FE2.50401@mail.berlios.de>
[-- Attachment #1: Type: text/plain, Size: 5019 bytes --]
Stefan Weil wrote:
> Jan Kiszka schrieb:
>> Alexander Graf wrote:
>>
>>> On 21.04.2010, at 12:04, Jun Koi wrote:
>>>
>>>
>>>> On Tue, Apr 20, 2010 at 8:44 PM, Alexander Graf <agraf@suse.de> wrote:
>>>>
>>>>> On 20.04.2010, at 13:38, Jan Kiszka wrote:
>>>>>
>>>>>
>>>>>> Alexander Graf wrote:
>>>>>>
>>>>>>> On 20.04.2010, at 09:18, Jan Kiszka wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Jun Koi wrote:
>>>>>>>>
>>>>>>>>> Thank you for the explanation of this code.
>>>>>>>>>
>>>>>>>>> Qemu has a command named singlestep, which reduces the translated code
>>>>>>>>> block to be only one instruction.
>>>>>>>>> This new patch flushes TBs both when singlestep is on and off.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Jun Koi <junkoi2004@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> diff --git a/monitor.c b/monitor.c
>>>>>>>>> index 5659991..2b2005b 100644
>>>>>>>>> --- a/monitor.c
>>>>>>>>> +++ b/monitor.c
>>>>>>>>> @@ -1187,13 +1187,26 @@ static void do_log(Monitor *mon, const QDict *qdict)
>>>>>>>>> cpu_set_log(mask);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> +/* flush all the TBs to force new code generation */
>>>>>>>>> +static void flush_all_tb(void)
>>>>>>>>> +{
>>>>>>>>> + CPUState *env;
>>>>>>>>> +
>>>>>>>>> + for (env = first_cpu; env != NULL; env = env->next_cpu) {
>>>>>>>>> + tb_flush(env);
>>>>>>>>> + }
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>>
>>>>>>>> The smaller your patch are, the more people pick on it. :)
>>>>>>>>
>>>>>>>> I was about to suggest moving this close to tb_flush, but then I
>>>>>>>> realized that the env argument of that service is misleading. In fact,
>>>>>>>> it already flushes the one and only translation buffer pool.
>>>>>>>>
>>>>>>>>
>>>>>>>>> static void do_singlestep(Monitor *mon, const QDict *qdict)
>>>>>>>>> {
>>>>>>>>> const char *option = qdict_get_try_str(qdict, "option");
>>>>>>>>> +
>>>>>>>>> if (!option || !strcmp(option, "on")) {
>>>>>>>>> singlestep = 1;
>>>>>>>>> + flush_all_tb();
>>>>>>>>> } else if (!strcmp(option, "off")) {
>>>>>>>>> singlestep = 0;
>>>>>>>>> + flush_all_tb();
>>>>>>>>> } else {
>>>>>>>>> monitor_printf(mon, "unexpected option %s\n", option);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Let's just pass mon->mon_cpu to tb_flush and skip the redundant loop.
>>>>>>>>
>>>>>>> That doesn't help, no? singlestep is a global variable. Flushing only the current vcpu would still not affect the others, while the singlestep switch would.
>>>>>>>
>>>>>> tb_flush uses env only to dump some state when a problem occurred.
>>>>>>
>>>>>>
>>>>>>> According to your above comment the cache is global, but I don't think we should rely on that.
>>>>>>>
>>>>>> It might make sense to define some tb_flush_all() as tb_flush(first_cpu)
>>>>>> for now to establish the infrastructure. Then we are prepared for the
>>>>>> day the tb_flush implementation may change.
>>>>>>
>>>>> Right. But then the call to tb_flush_all here is still correct.
>>>>>
>>>> So what is the final solution do you want?
>>>>
>>>> I still think that having flush_all_tb() like in the last patch is good enough.
>>>>
>>> I agree. And I like the patch as is.
>>>
>>> Acked-by: Alexander Graf <agraf@suse.de>
>>>
>>>
>> Sorry, nack for keeping this service in /monitor.c/. But a bonus ack if
>> you avoid the needless loop when moving it to exec.c, adding a comment
>> that current tb_flush has global, env-invariant scope.
>>
>> Thanks,
>> Jan
>
> flush_all_tb() is now called for singlestep on and off, that's fine.
> But it's called always - no way to disable this call. That's not good.
> Sometimes I don't want to flush all TBs when I switch singlestep mode
> (that's the reason why I suggested a separate monitor command which
> flushes all TBs - I still think that would be the best solution).
Mind to tell us the use case?
>
> What about this syntax for the singlestep monitor command:
>
> singlestep [on|off][,flush]
> Run the emulation in single step mode. In that mode, QEMU uses
> one translation block per target CPU instruction.
> If called with option off, the emulation returns to normal mode.
> If called with the optional parameter flush, existing translation
> blocks are flushed.
>
> Or, if you prefer to flush by default:
>
> singlestep [on|off][,noflush]
> Run the emulation in single step mode. In that mode, QEMU uses
> one translation block per instructions.
> ...
If we need this knob, then this version please (not wanting to flush is
likely the corner case).
>
> Please update qemu-monitor.hx, too (that should be done in any case).
Right, and the qemu-options.hx needs update as well to explain that
"singlestep" has nothing to do with debugger single-stepping.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2010-04-22 7:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-16 1:03 [Qemu-devel] [PATCH] flush TB on singlestep command Jun Koi
2010-04-16 21:13 ` Stefan Weil
2010-04-20 1:17 ` Jun Koi
2010-04-20 7:18 ` [Qemu-devel] " Jan Kiszka
2010-04-20 10:51 ` Alexander Graf
2010-04-20 11:38 ` Jan Kiszka
2010-04-20 11:44 ` Alexander Graf
2010-04-21 10:04 ` Jun Koi
2010-04-21 10:11 ` Alexander Graf
2010-04-21 10:43 ` Jan Kiszka
2010-04-21 19:20 ` Stefan Weil
2010-04-22 7:02 ` Jan Kiszka [this message]
2010-04-27 19:55 ` Stefan Weil
2010-04-27 23:50 ` Jun Koi
2010-04-28 18:06 ` Stefan Weil
2010-04-22 7:14 ` Jun Koi
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=4BCFF490.6060407@web.de \
--to=jan.kiszka@web.de \
--cc=agraf@suse.de \
--cc=junkoi2004@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=weil@mail.berlios.de \
/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).