Re: [PATCH v2 14/21] qemu-kvm: Rework VCPU state writeback API

[Avi Kivity <avi@redhat.com>]

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