[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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: 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
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.


error compiling committee.c: too many arguments to function

reply via email to

[Prev in Thread] Current Thread [Next in Thread]