Re: cpu_counter_serializing() vs. QEMU

[christos%astron.com@localhost (Christos Zoulas)]

In article 
<CADbF7ecS=vXJFuhZWeyx+5P2NmCj6wy4AAkJRfVL_yO-S9dLvw%mail.gmail.com@localhost>,
Masao Uebayashi  <uebayasi%gmail.com@localhost> wrote:
>Intel(R) 64 and IA-32 Architectures Software Developer?s Manual
>Volume 3 (3A, 3B & 3C): System Programming Guide
>17.13 TIME-STAMP COUNTER
>
>    TSC flag - A feature bit that indicates the availability of the
>time-stamp counter.
>    The counter is available in an if the function CPUID.1:EDX.TSC[bit 4] = 1.
>
>On Fri, Jun 21, 2013 at 7:10 AM, Jeff Rizzo <riz%tastylime.net@localhost> 
>wrote:
>> This all came about because I discovered that "modload dtrace" while running
>> under QEMU (amd64, but I bet the same thing happens under i386) panics the
>> kernel, because tsc_freq is 0.  Hm.
>>
>> Digging a little deeper, in sys/arch/x86/x86/tsc.c:
>>
>> uint64_t
>> cpu_counter_serializing(void)
>> {
>>         if (cpu_feature[0] & CPUID_MSR)
>>                 return rdmsr(MSR_TSC);
>>         else
>>                 return cpu_counter();
>> }
>>
>>
>> Under QEMU, rdmsr(MSR_TSC) always returns 0, because that MSR isn't
>> implemented (apparently).  If I hardcode cpu_counter_serializing() to always
>> return cpu_counter(), things work just fine.
>>
>> A couple things:
>>
>> - is testing (cpu_feature[0] & CPUID_MSR) the right test?  Only some MSRs
>> are implemented.
>
>I don't think so.
>
>> - if that test is correct, what's the right way/best place to check if
>> rdmsr(MSR_TSC) returns 0, and hence use cpu_counter() instead?
>>
>> I'd be surprised if dtrace is the only thing suffering because of this...
>
>Me too.

I would add something in the cpu identify code to detect QEMU and clear
CPUID_MSR.

christos