Please follow the instructions from bug 1081394 comment 61 on RHEL 7.

# /usr/libexec/qemu-kvm  --enable-kvm -cpu SandyBridge,hv_time -kernel
cpuid_dump_kernel.bin  -serial stdio

   0x40000003 0x00: eax=0x00000222 ebx=0x00000000 ecx=0x00000000 edx=0x00000000

AccessPartitionReferenceCounter, AccessHypercallMsrs, AccessPartitionReferenceTsc.

The spec says bit 6 (AccessVpIndex) is mandatory.  Do we need a patch like this?

diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index a26d25a..f62e83c 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -501,17 +501,13 @@ int kvm_arch_init_vcpu(CPUState *cs)
 
         c = &cpuid_data.entries[cpuid_i++];
         c->function = HYPERV_CPUID_FEATURES;
-        if (cpu->hyperv_relaxed_timing) {
-            c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
-        }
+        c->eax = HV_X64_MSR_HYPERCALL_AVAILABLE | HV_X64_MSR_VP_INDEX_AVAILABLE;
         if (cpu->hyperv_vapic) {
-            c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
             c->eax |= HV_X64_MSR_APIC_ACCESS_AVAILABLE;
             has_msr_hv_vapic = true;
         }
         if (cpu->hyperv_time &&
             kvm_check_extension(cs->kvm_state, KVM_CAP_HYPERV_TIME) > 0) {
-            c->eax |= HV_X64_MSR_HYPERCALL_AVAILABLE;
             c->eax |= HV_X64_MSR_TIME_REF_COUNT_AVAILABLE;
             c->eax |= 0x200;
             has_msr_hv_tsc = true;

I'll look into it early next week.

Thorsten, can you check if the customer can use hv_time after doing the following:

 bcdedit /set {current} useplatformclock no

Created attachment 1042238 [details]
coreinfo.txt

Created attachment 1042240 [details]
process.txt

Created attachment 1042242 [details]
qemu-monitor.txt

Ouch, the VM does not have time drift compensation active!  The -rtc-td-hack option (newer QEMUs have a more reassuring version "-global mc146818rtc.lost_tick_policy=slew") is not present.  This is inserted by libvirt when it sees this in the XML:

  <clock ...>
    <timer name='rtc' tickpolicy='catchup'/>
  </clock>

Either vdsm or RHEV-M should do that automatically for Windows guests.

(In reply to Paolo Bonzini from comment #30)
> Ouch, the VM does not have time drift compensation active!  The -rtc-td-hack
> option (newer QEMUs have a more reassuring version "-global
> mc146818rtc.lost_tick_policy=slew") is not present.  This is inserted by
> libvirt when it sees this in the XML:
> 
>   <clock ...>
>     <timer name='rtc' tickpolicy='catchup'/>
>   </clock>
> 
> Either vdsm or RHEV-M should do that automatically for Windows guests.

Paolo, how does hypervclock and rtc co-exist? Should we use both rtc and hypervclock? Currently indeed when hyperv enlightments are enabled we do not send rtc, but only: hypervclock,pit, and explicitly disable hpet.

patch merged (https://gerrit.ovirt.org/#/c/43195/)

To verify, start a windows vm and make sure that the domain XML contains a snippet like

            <clock ... offset="variable">
                ...
                <timer name="hypervclock"/>
                <timer name="rtc" tickpolicy="catchup"/>
                ...

(In reply to Francesco Romani from comment #41)
> To verify, start a windows vm and make sure that the domain XML contains a
> snippet like
> 
>             <clock ... offset="variable">
>                 ...
>                 <timer name="hypervclock"/>
>                 <timer name="rtc" tickpolicy="catchup"/>
>                 ...

Verified with rhevm-3.6.1.3-0.1.el6.noarch.

created a windows 7 X64 vm and started it.

in vm's xml dump the clock entity is as follows:

  <clock offset='variable' adjustment='0' basis='utc'>
    <timer name='hypervclock' present='yes'/>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0362.html