From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ne7eL-00011i-2E for qemu-devel@nongnu.org; Sun, 07 Feb 2010 08:58:09 -0500 Received: from [199.232.76.173] (port=40525 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ne7eK-000118-Iw for qemu-devel@nongnu.org; Sun, 07 Feb 2010 08:58:08 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Ne7eJ-0006be-S4 for qemu-devel@nongnu.org; Sun, 07 Feb 2010 08:58:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18595) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ne7eJ-0006bY-EI for qemu-devel@nongnu.org; Sun, 07 Feb 2010 08:58:07 -0500 Message-ID: <4B6EC6EC.4020509@redhat.com> Date: Sun, 07 Feb 2010 15:58:04 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4822161334c3e10d7772dbd08dafdd3a78c86ce4.1265187223.git.jan.kiszka@siemens.com> <4B6EC180.7000203@redhat.com> <4B6EC557.9090804@web.de> In-Reply-To: <4B6EC557.9090804@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v2 14/21] qemu-kvm: Rework VCPU state writeback API List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , kvm@vger.kernel.org, Glauber Costa , Marcelo Tosatti , qemu-devel@nongnu.org, Alexander Graf On 02/07/2010 03:51 PM, Jan Kiszka wrote: > Avi Kivity wrote: > >> On 02/03/2010 10:53 AM, Jan Kiszka wrote: >> >>> This grand cleanup drops all reset and vmsave/load related >>> synchronization points in favor of four(!) generic hooks: >>> >>> - cpu_synchronize_all_states in qemu_savevm_state_complete >>> (initial sync from kernel before vmsave) >>> - cpu_synchronize_all_post_init in qemu_loadvm_state >>> (writeback after vmload) >>> - cpu_synchronize_all_post_init in main after machine init >>> - cpu_synchronize_all_post_reset in qemu_system_reset >>> (writeback after system reset) >>> >>> These writeback points + the existing one of VCPU exec after >>> cpu_synchronize_state map on three levels of writeback: >>> >>> - KVM_PUT_ASYNC_STATE (during runtime, other VCPUs continue to run) >>> >>> >> Wouldn't that be SYNC_STATE (state that is modified by the current vcpu >> only)? >> > It's async /wrt other VCPUs. They continue to run and may interact with > this VCPU while updating its state. > Well, to me it makes more sense to name them from the point of view of the vcpu that is doing the update. >> I'm uneasy about this. What are the rules for putting >> cpu_synchronize_state() now? >> > As before for code that accesses the state during runtime: Before you > read or write some bit of it, call cpu_synchronize_state(). > > Only reset and save/restore handlers do not have to worry about > synchronization anymore. It makes no sense to overload them with > arch-specific KVM knowledge about what shall be written and when. > OK. -- error compiling committee.c: too many arguments to function