From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v2 14/21] qemu-kvm: Rework VCPU state writeback API Date: Sun, 07 Feb 2010 15:58:04 +0200 Message-ID: <4B6EC6EC.4020509@redhat.com> References: <4822161334c3e10d7772dbd08dafdd3a78c86ce4.1265187223.git.jan.kiszka@siemens.com> <4B6EC180.7000203@redhat.com> <4B6EC557.9090804@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm@vger.kernel.org, Anthony Liguori , Alexander Graf , Glauber Costa , qemu-devel@nongnu.org To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:62158 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751141Ab0BGN6U (ORCPT ); Sun, 7 Feb 2010 08:58:20 -0500 In-Reply-To: <4B6EC557.9090804@web.de> Sender: kvm-owner@vger.kernel.org List-ID: 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