On 17.01.2014, at 07:13, Alexey Kardashevskiy <a...@ozlabs.ru> wrote:
> The kvm_cpu_exec() only puts registers to KVM if the @kvm_vcpu_dirty flag
> has been set.
>
> This adds registers sync which also sets @kvm_vcpu_dirty so we store new
> LPCR to KVM before continuing with the KVM_RUN ioctl.
>
> Signed-off-by: Alexey Kardashevskiy <a...@ozlabs.ru>
> ---
> hw/ppc/spapr_hcall.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index f755a53..b61d744 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -682,6 +682,7 @@ static target_ulong h_set_mode(PowerPCCPU *cpu,
> sPAPREnvironment *spapr,
> CPU_FOREACH(cs) {
> PowerPCCPU *cp = POWERPC_CPU(cs);
> CPUPPCState *env = &cp->env;
> + kvm_cpu_synchronize_state(cs);
This should be cpu_synchronize_state(). But even then I'm not 100% sure we're
not racy. What guarantees that the other vcpu doesn't go back into the guest
before we fiddle with its LPCR?
We might have to put the LPCR fiddling and synchronization into a single
function we call through run_on_cpu().
Alex
