From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juan Quintela Subject: KVM call minutes for 2013-10-01 Date: Tue, 01 Oct 2013 16:54:10 +0200 Message-ID: <8761th82jx.fsf@elfo.elfo> Reply-To: quintela@redhat.com Mime-Version: 1.0 Content-Type: text/plain To: KVM devel mailing list , qemu-devel qemu-devel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:62647 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751573Ab3JAOyR (ORCPT ); Tue, 1 Oct 2013 10:54:17 -0400 Sender: kvm-owner@vger.kernel.org List-ID: 2013-10-01 ---------- - acpi generation patches - ok to merge? - Talk about qemu reverse executing (1st description was done this week) How to handle IO when we want to do reverse execution. How this relate to Kemari needs? And to icount changes? a- Save state every second. When something happens, you restore to last state and reexecute to current instruction. 3-4 times more to run, too slow. no IO allowed b- instead of saving the state of the machine, fork. Being careful. Fork each time we want one snapshot It almost don't affect qemu speed Only see what happened, no way to do the "timeback machine" enable/disable as you wish Issue: Saving the icount. It is not on vmstate. Problem with the things that are not deterministic icount not used very much there - exec in reverse: cexe - Multicore on Multicore: TCG has no locking, no people really working there (Alex Graf?) Will get the patches upstream as RFC and go from here. Fork() has the advantage of speed, and the disadvantage of .... threads? Moved to other day to compare with Kemari. Later, Juan.