Re: cpu_counter_serializing() vs. QEMU

[Jeff Rizzo <riz%tastylime.net@localhost>]

On 6/22/13 8:14 AM, Jeff Rizzo wrote:
> On 6/20/13 7:26 PM, Masao Uebayashi 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.
>
> We're already doing this check - I think the problem stems from the 
> fact that QEMU doesn't implement the MSR - it *does* seem to implement 
> rdtsc, though, which seems to be a non-serializing version.  Are you 
> suggesting we should disable TSC entirely for QEMU?  How will this 
> affect non-serializing uses?
>
> > On Fri, Jun 21, 2013 at 7:10 AM, Jeff Rizzo <riz%tastylime.net@localhost> wrote:
> > > - is testing (cpu_feature[0] & CPUID_MSR) the right test? Only some 
> > > MSRs
> > > are implemented.
> > I don't think so.
> Should we be inventing some new test for "partial TSC support"? Should 
> we just disable TSC in QEMU entirely?

More info:

- turning off TSC support (via cpu_feature[0]) does not actually help me 
get dtrace running, because tsc_freq is still 0.

- turning off MSR support (via cpu_feature[0]) _does_ help, because 
cpu_counter() is chosen in cpu_counter_serializing().

Now, it can surely be argued that QEMU is broken because it only partly 
implements the TSC, but that's not going to help my immediate goal which 
is to have NetBSD dtrace working under qemu.  I'd like to implement some 
flag during cpu_probe() which basically says which thing to use in 
cpu_counter_serializing() without other side effects.


+j