From patchwork Thu Apr 15 04:10:18 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jun Koi X-Patchwork-Id: 50212 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 97A27B7D00 for ; Thu, 15 Apr 2010 14:11:23 +1000 (EST) Received: from localhost ([127.0.0.1]:50019 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O2GQA-0005FD-Go for incoming@patchwork.ozlabs.org; Thu, 15 Apr 2010 00:11:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O2GPa-0005EQ-AP for qemu-devel@nongnu.org; Thu, 15 Apr 2010 00:10:42 -0400 Received: from [140.186.70.92] (port=50575 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O2GPZ-0005Dv-1u for qemu-devel@nongnu.org; Thu, 15 Apr 2010 00:10:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O2GPX-0004cN-HW for qemu-devel@nongnu.org; Thu, 15 Apr 2010 00:10:40 -0400 Received: from mail-iw0-f194.google.com ([209.85.223.194]:47927) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2GPX-0004c0-DL for qemu-devel@nongnu.org; Thu, 15 Apr 2010 00:10:39 -0400 Received: by iwn32 with SMTP id 32so348431iwn.18 for ; Wed, 14 Apr 2010 21:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type; bh=QEfj5oAyoSzzY5cphcTTX8i36w3frFFTD3jA+uSO9vg=; b=JWGj9E8q+eVId69yOO2GccMYquxZdGepp8oT3gc4H0k54nP63sirEjqdqUY2g6ato3 UmdW4EmtTo1dI38RiDpemnMgDy6K2USpFOcNQu+XCHzewsUCcUx7hEA4h5Kcsu6CnBqH qpwddig8Qn/F6+xUD2e154FiqhlD0HDoUFFJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=tTRwl/3oszk/6C/WzVjkaWcfF51140BAWYL/uFLVCyiBb7nAqRrEaoLc2PBcvmIf1u ktWNoM+d8xQkb+GOiWrIkIXRuNp7Or2/JCil5ZpKnG20VtSmNuMwIGEF2918a1uPsDKY DHxGdS/yuchi5mk3L5JfjAqHs/RP+Ty9dKBm0= MIME-Version: 1.0 Received: by 10.231.147.209 with HTTP; Wed, 14 Apr 2010 21:10:18 -0700 (PDT) In-Reply-To: <4BC48D85.7050903@siemens.com> References: <4BC47340.3030407@siemens.com> <4BC48D85.7050903@siemens.com> From: Jun Koi Date: Thu, 15 Apr 2010 13:10:18 +0900 Received: by 10.231.174.142 with SMTP id t14mr3282268ibz.69.1271304638092; Wed, 14 Apr 2010 21:10:38 -0700 (PDT) Message-ID: Subject: Re: [Qemu-devel] Re: Missing singlestep for already-translated code? To: Jan Kiszka X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: Alexander Graf , "qemu-devel@nongnu.org" X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On Wed, Apr 14, 2010 at 12:28 AM, Jan Kiszka wrote: > Alexander Graf wrote: >> On 13.04.2010, at 15:36, Jan Kiszka wrote: >> >>> Jun Koi wrote: >>>> Hi, >>>> >>>> I am looking into the singlestep command in monitor interface, and it >>>> seems that we only take into account the singlestep flag when we are >>>> translating code. >>>> So for the already-translated code, we will miss singlestep? >>> This feature is broken. For TCG, it should at least flush the >>> translation buffer, and for KVM it has to enable single-stepping in the >>> kernel. That's what happens automatically when you call cpu_single_step. >>> I guess 'singlestep' wants to be somehow orthogonal to this. But this is >>> the wrong approach. >>> >>> Does anyone actually used this feature or still does so? It looks fairly >>> redundant to me, kind of a poor-man's gdb front-end as part of the >>> monitor console. >> >> Not sure what it does, but I use -singlestep quite a lot to get register dumps for instructions when using -d cpu. > > Ah, "singlestep" is not about stopping the VM after each instruction but > about limiting the TB length to a single instruction. Badly named and > poorly documented. > > In that case, the dynamic switch should already be fine by adding a > tb_flush() on enable. Still, someone should also patch at least the docs. > Do you have any comment on the below patch? Thanks, J diff --git a/monitor.c b/monitor.c index 5659991..dfa9820 100644 --- a/monitor.c +++ b/monitor.c @@ -1190,8 +1190,13 @@ static void do_log(Monitor *mon, const QDict *qdict) static void do_singlestep(Monitor *mon, const QDict *qdict) { const char *option = qdict_get_try_str(qdict, "option"); + CPUState *env; + if (!option || !strcmp(option, "on")) { singlestep = 1; + /* flush all the TB to force new code generation */ + for (env = first_cpu; env != NULL; env = env->next_cpu) + tb_flush(env); } else if (!strcmp(option, "off")) { singlestep = 0; } else {