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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
