[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: cpu_counter_serializing() vs. QEMU
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
> 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>
>> 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:
>> if (cpu_feature & CPUID_MSR)
>> return rdmsr(MSR_TSC);
>> 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 & 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...
I would add something in the cpu identify code to detect QEMU and clear
Main Index |
Thread Index |