|
From: | Avi Kivity |
Subject: | [Qemu-devel] Re: [PATCH v2 14/21] qemu-kvm: Rework VCPU state writeback API |
Date: | Sun, 07 Feb 2010 15:58:04 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |