Port-amd64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: cpu_counter_serializing() vs. QEMU



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




Home | Main Index | Thread Index | Old Index