On 11/30/18 5:17 PM, Paolo Bonzini wrote: > On 30/11/18 22:38, Wei Huang wrote: >> Obviously the >> code is expecting the APIC_TMCCT counter will be reset to the initial >> value stored in APIC_TMICT, right after the counter reach zero (it is a >> periodic timer anyway). However this assumption shouldn't be held true >> all the time. It is possible the test code will reads APIC_TMCCT before >> the reset happens. If this happens, the test will fail. In fact, in my >> experiment, it is quite common (>20% of chance) to see APIC_TMCCT 0 on >> Intel "E3-1220 V2" CPU. >> > > This is an emulated device, so I'm quite surprised that this can happen > only on one processor. It is possible, or perhaps even likely, that you > stumbled upon a processor bug. > > Can you try reloading kvm_intel with the enable_preemption_timer > parameter set to 0? If it passes, we need to add that Xeon to the list preemption_timer=0 did solve the problem. So we might need to add this one into the list. > of broken CPUs, so that cpu_has_broken_vmx_preemption_timer filters it > out. The only information needed for that is CPUID[1].EAX. The CPUID[1].EAX value is 0x000306A8 on this CPU. Interestingly I can't find any info related to this CPU by searching intel+xeon+"000306A8h" on google. The next stepping, 0x000306A9h, can be found easily. So this might be a non-production CPU (?) Not sure. > > Thanks, > > Paoo >
