Re: cpu_counter_serializing() vs. QEMU

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

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.

>
> +j
>