qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/3] make hyperv hypercall, vapic, and os id MSR


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 2/3] make hyperv hypercall, vapic, and os id MSRs migratable
Date: Tue, 21 Jan 2014 11:17:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

Il 21/01/2014 09:02, Vadim Rozenfeld ha scritto:
> Signed-off-by: Vadim Rozenfeld <address@hidden>
> ---
>  target-i386/cpu.h     |  4 ++++
>  target-i386/kvm.c     | 30 +++++++++++++++++++++++++-----
>  target-i386/machine.c | 24 ++++++++++++++++++++++++
>  3 files changed, 53 insertions(+), 5 deletions(-)
> 
> diff --git a/target-i386/cpu.h b/target-i386/cpu.h
> index 1d94a9d..6eeafdc 100644
> --- a/target-i386/cpu.h
> +++ b/target-i386/cpu.h
> @@ -847,6 +847,10 @@ typedef struct CPUX86State {
>      uint64_t msr_gp_counters[MAX_GP_COUNTERS];
>      uint64_t msr_gp_evtsel[MAX_GP_COUNTERS];
>  
> +    uint64_t msr_hv_hypercall;
> +    uint64_t msr_hv_guest_os_id;
> +    uint64_t msr_hv_vapic;
> +
>      /* exception/interrupt handling */
>      int error_code;
>      int exception_is_int;
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 768ca1d..5152e64 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -1185,12 +1185,15 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
>              kvm_msr_entry_set(&msrs[n++], MSR_CORE_PERF_GLOBAL_CTRL,
>                                env->msr_global_ctrl);
>          }
> -        if (hyperv_hypercall_available(cpu)) {
> -            kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID, 0);
> -            kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL, 0);
> +        if (has_msr_hv_hypercall) {
> +            kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_GUEST_OS_ID,
> +                              env->msr_hv_guest_os_id);
> +            kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_HYPERCALL,
> +                              env->msr_hv_hypercall);
>          }
> -        if (cpu->hyperv_vapic) {
> -            kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
> +        if (has_msr_hv_vapic) {
> +            kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE,
> +                              env->msr_hv_vapic);
>          }

Changing the "if" condition should go in (one of the patches split out
of) the previous patch.

>          if (has_msr_feature_control) {
>              kvm_msr_entry_set(&msrs[n++], MSR_IA32_FEATURE_CONTROL,
> @@ -1470,6 +1473,14 @@ static int kvm_get_msrs(X86CPU *cpu)
>          }
>      }
>  
> +    if (has_msr_hv_hypercall) {
> +        msrs[n++].index = HV_X64_MSR_HYPERCALL;
> +        msrs[n++].index = HV_X64_MSR_GUEST_OS_ID;
> +    }
> +    if (has_msr_hv_vapic) {
> +        msrs[n++].index = HV_X64_MSR_APIC_ASSIST_PAGE;
> +    }
> +
>      msr_data.info.nmsrs = n;
>      ret = kvm_vcpu_ioctl(CPU(cpu), KVM_GET_MSRS, &msr_data);
>      if (ret < 0) {
> @@ -1574,6 +1585,15 @@ static int kvm_get_msrs(X86CPU *cpu)
>          case MSR_P6_EVNTSEL0 ... MSR_P6_EVNTSEL0 + MAX_GP_COUNTERS - 1:
>              env->msr_gp_evtsel[index - MSR_P6_EVNTSEL0] = msrs[i].data;
>              break;
> +        case HV_X64_MSR_HYPERCALL:
> +            env->msr_hv_hypercall = msrs[i].data;
> +            break;
> +        case HV_X64_MSR_GUEST_OS_ID:
> +            env->msr_hv_guest_os_id = msrs[i].data;
> +            break;
> +        case HV_X64_MSR_APIC_ASSIST_PAGE:
> +            env->msr_hv_vapic = msrs[i].data;
> +            break;
>          }
>      }
>  
> diff --git a/target-i386/machine.c b/target-i386/machine.c
> index e568da2..58c5b45 100644
> --- a/target-i386/machine.c
> +++ b/target-i386/machine.c
> @@ -506,6 +506,27 @@ static const VMStateDescription 
> vmstate_msr_architectural_pmu = {
>      }
>  };
>  
> +static bool hyperv_enable_needed(void *opaque)
> +{
> +    X86CPU *cpu = opaque;
> +    CPUX86State *env = &cpu->env;
> +
> +    return env->msr_hv_hypercall != 0;

I think you should test all three MSRs.  It is theoretically possible
that a guest OS writes the guest OS ID MSR first and the machine is
migrated exactly after that write.

Paolo

> +}
> +
> +static const VMStateDescription vmstate_msr_hyperv = {
> +    .name = "cpu/msr_hyperv",
> +    .version_id = 1,
> +    .minimum_version_id = 1,
> +    .minimum_version_id_old = 1,
> +    .fields      = (VMStateField []) {
> +        VMSTATE_UINT64(env.msr_hv_hypercall, X86CPU),
> +        VMSTATE_UINT64(env.msr_hv_guest_os_id, X86CPU),
> +        VMSTATE_UINT64(env.msr_hv_vapic, X86CPU),
> +        VMSTATE_END_OF_LIST()
> +    }
> +};
> +
>  const VMStateDescription vmstate_x86_cpu = {
>      .name = "cpu",
>      .version_id = 12,
> @@ -637,6 +658,9 @@ const VMStateDescription vmstate_x86_cpu = {
>          }, {
>              .vmsd = &vmstate_msr_architectural_pmu,
>              .needed = pmu_enable_needed,
> +        }, {
> +            .vmsd = &vmstate_msr_hyperv,
> +            .needed = hyperv_enable_needed,
>          } , {
>              /* empty */
>          }
> 




reply via email to

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