From patchwork Mon Aug 17 11:14:02 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 507946 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 68DDA140129 for ; Mon, 17 Aug 2015 21:14:32 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=RoiiLQoD; dkim-atps=neutral Received: from localhost ([::1]:55011 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZRIN2-0001VT-8v for incoming@patchwork.ozlabs.org; Mon, 17 Aug 2015 07:14:28 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51701) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZRIMk-00019r-54 for qemu-devel@nongnu.org; Mon, 17 Aug 2015 07:14:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZRIMg-0004eg-TR for qemu-devel@nongnu.org; Mon, 17 Aug 2015 07:14:10 -0400 Received: from mail-pd0-x234.google.com ([2607:f8b0:400e:c02::234]:34910) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZRIMg-0004dM-IH for qemu-devel@nongnu.org; Mon, 17 Aug 2015 07:14:06 -0400 Received: by pdrg1 with SMTP id g1so54953610pdr.2 for ; Mon, 17 Aug 2015 04:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=PB4xbHKaLJb+uBXtA//5WGFt8TaXRi5V0XLQLciShL4=; b=RoiiLQoD5OA1Gi9r/ZLl6DW1edI5HvkcK3zNROEWar1YYlLDV5WD9FhO68jkuJGKZB HroweLOCXrva+mH6/bEGI9QoVPswj3Ih7785Hs5rZQJM4UQI58nE6LTYAJ4r+DpRyAJx tSG4KRemfKFFQMAfaE7p6d5OEat8nQ+JkCibhgyfd91N6Xz2qkht4VkQIsz00rtIzcOy mg94bE6dPD2g6f6HIPoB1pX0XzXg9AGs7/rF+9R7Em2k8Od3n9pcD5nW7XAttuY+D/MS gVWLicnh+Ux7IM2vzVsAkCCuVTsWcN4n4f6okBdk4ZNwZvCmSBvM0KF5ZR3Zyl4Ktaoa HwIg== X-Received: by 10.70.119.66 with SMTP id ks2mr1676237pdb.11.1439810045137; Mon, 17 Aug 2015 04:14:05 -0700 (PDT) Received: from [172.16.10.245] ([128.177.170.246]) by smtp.googlemail.com with ESMTPSA id kp5sm14326720pdb.57.2015.08.17.04.14.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2015 04:14:03 -0700 (PDT) To: Pavel Dovgalyuk References: <20150804084345.7280.75100.stgit@PASHA-ISP> <1439632667084-f9fa3e34-9aae8b42-26b94d77@ispras.ru> <55CF0E89.7070701@redhat.com> From: Paolo Bonzini X-Enigmail-Draft-Status: N1110 Message-ID: <55D1C1FA.2040109@redhat.com> Date: Mon, 17 Aug 2015 13:14:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55CF0E89.7070701@redhat.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c02::234 Cc: peter.maydell@linaro.org, igor.rubinov@gmail.com, mark.burton@greensocs.com, qemu-devel@nongnu.org, hines@cert.org, Peter Crosthwaite , maria.klimushenkova@ispras.ru, real@ispras.ru, batuzovk@ispras.ru, alex.bennee@linaro.org, fred.konrad@greensocs.com Subject: Re: [Qemu-devel] [PATCH v16 00/21] Deterministic replay core X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org On 15/08/2015 12:03, Paolo Bonzini wrote: > > > On 15/08/2015 11:57, Pavel Dovgalyuk wrote: >> Hi, Paolo! >> >> Will you apply these patches to 2.5? > > Yes, I'll put them in my next pull request. Hi Pavel, unfortunately I do have some more review comments; that can happen when going back to the code after a few months, and it's also a good thing because it means that the code _is_ actually getting cleaner. However, I am fairly sure that v17 is going to be the good one and will be in 2.5 if I get it by mid September when I'll be back from vacation. In particular: * patch 3 seems to be unnecessary (for now at least) * replay_next_event_is is modified in patch 8 ("cpu: replay instructions sequence") after it's introduced in patch 6 ("replay: introduce icount event"). Please fold the change in patch 6. * replay_add_event is not used; please remove it, rename replay_add_event_internal to replay_add_event, and add an assertion that the rr mode is the right one (e.g. RECORD only?) * a couple of comments say "grteater" instead of "greater" * the replay_save_clock and replay_read_clock stubs should abort * please inline replay_input_event into qemu_input_event_send and replay_input_sync_event into qemu_input_event_sync, so that the corresponding *_impl functions can be static; this also means moving the prototypes of replay_add_input_event and replay_add_input_sync_event to replay/replay.h (I acknowledge this might undo a request from a previous review of mine; I don't remember) * most stubs are unnecessary (replay_get_current_step, replay_checkpoint, qemu_system_shutdown_request, qemu_input_event_send_impl, qemu_input_event_sync_impl) * please squash this in "replay: checkpoints" And a few questions. The first three are the "if the answer is yes, please do this" kind to questions, the others can have more open/subjective answers: * does it make sense to call replay_check_error from replay_finish_event, and remove the call from replay_read_next_clock? * should qemu_clock_use_for_deadline always return false in replay mode? The clocks are all deterministic, so it doesn't make sense to take them into account in the poll() deadline. * now that qemu_clock_warp has to be called in main_loop_wait, should the icount_warp_timer have a dummy callback? icount_warp_rt is then only called from qemu_clock_warp. If so, this (adding the call to qemu_clock_warp in main_loop_wait, making the icount_warp_timer dummy, removing the now-unnecessary argument of icount_warp_rt) should be a separate patch before "replay: checkpoints" * can you explain why both CHECKPOINT_INIT and CHECKPOINT_RESET are needed? What events are typically found in each of them? * would it make sense to test "replay_mode != REPLAY_MODE_NONE && !runstate_is_running()" in replay_checkpoint, for all checkpoints, like if (replay_mode != REPLAY_MODE_NONE && !runstate_is_running()) { return false; } ? * do we need an event for suspend? Thanks, Paolo diff --git a/vl.c b/vl.c index 5a509dc..3c69563 100644 --- a/vl.c +++ b/vl.c @@ -1662,8 +1662,11 @@ static void qemu_kill_report(void) static int qemu_reset_requested(void) { int r = reset_requested; - reset_requested = 0; - return r; + if (r && replay_checkpoint(CHECKPOINT_RESET_REQUESTED)) { + reset_requested = 0; + return r; + } + return false; } static int qemu_suspend_requested(void) @@ -1862,9 +1865,7 @@ static bool main_loop_should_exit(void) return true; } } - if (qemu_reset_requested_get() - && replay_checkpoint(CHECKPOINT_RESET_REQUESTED)) { - qemu_reset_requested(); + if (qemu_reset_requested()) { pause_all_vcpus(); cpu_synchronize_all_states(); qemu_system_reset(VMRESET_REPORT);