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

Avi Kivity
2010-02-07T13:58:20Z

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