2016-10-18 19:05-0200, Eduardo Habkost:
> On Tue, Oct 18, 2016 at 10:52:14PM +0200, Radim Krčmář wrote:
> [...]
>> The main problem is that QEMU changes virtual_tsc_khz when migrating
>> without hardware scaling, so KVM is forced to get nanoseconds wrong ...
>>
>> If QEMU doesn't want to keep the TSC frequency constant, then it would
>> be better if it didn't expose TSC in CPUID -- guest would just use
>> kvmclock without being tempted by direct TSC accesses.
>
> Isn't enough to simply not expose invtsc? Aren't guests expected
> to assume the TSC frequency can change if invtsc isn't set on
> CPUID?
There are exceptions. An OS can assume constant TSC on some models that
QEMU emulates: coreduo, core2duo, Conroe, Penryn, n270, kvm32 and kvm64.
The list from SDM (17.15 TIME-STAMP COUNTER):
Pentium 4 processors, Intel Xeon processors (family [0FH], models [03H
and higher]); Intel Core Solo and Intel Core Duo processors (family
[06H], model [0EH]); the Intel Xeon processor 5100 series and Intel
Core 2 Duo processors (family [06H], model [0FH]); Intel Core 2 and
Intel Xeon processors (family [06H], DisplayModel [17H]); Intel Atom
processors (family [06H], DisplayModel [1CH]))
Another sad part is that Linux uses the following condition to assume
constant TSC frequency:
if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
(c->x86 == 0x6 && c->x86_model >= 0x0e))
set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
which returns sets constant TSC for all modern processors. It's not a
problem on real hardware, because all modern processors likely have
invariant TSC.
Fun fact: Linux shows constant_tsc flag in /proc/cpuinfo even if the
modern CPU doesn't expose TSC in CPUID.
Considering that Linux is fixed on Nehalem and newer processors, we have
few options for the rest:
1) treat TSC like invariant TSC on those models (the guest cannot use
ACPI state, so its OS might assume that they are equivalent)
2) hide TSC on those models
3) ignore the problem
4) remove those models
I don't know enough about QEMU design goals to guess which one is the
most appropriate. (4) is the clear winner for me, followed by (3). :)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
