On Tue, May 06, 2014 at 03:27:20PM +0200, Ján Tomko wrote:
Not yet merged in upstream QEMU:
https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg05024.html
Add support for invariant TSC timer running at constant rate in
all ACPI P-, C- and T-states.
What does this do at the hardware level ? This doesn't seem to be
creating a second TSC timer source in the guest, rather it is
setting a property related to the existing TSC timer. So I think
it might make more sense as an attribute for <timer name='tsc'>
element instead.
It can be enabled by specifying:
<clock>
<timer name='invtsc' present='yes'/>
</clock>
in the domain XML.
Migration and saving the domain does not work with this timer.
Why is that ? The QEMU patch doesn't mention this restriction.
The support for this timer is indicated by bit 8 of EDX after calling
CPUID with 0x80000007. It does not show up in /proc/cpuinfo [1]
and since we're calling qemu without 'enforce', it doesn't error
out if the host doesn't support this.
Maybe I'm mis-interpreting the kernel source, but my reading of
that was that this *does* show up in /proc/cpuinfo, but it is
given the name 'constant_tsc' instead of 'invtsc'.
On my host I see 'constant_tsc' and 'nonstop_tsc' in /proc/cpuinfo
Alternatively, we could expose it in libvirt as a cpu flag:
<cpu mode='custom' match='exact'>
<model fallback='forbid'>qemu64</model>
<feature policy='require' name='invtsc'/>
</cpu>
or maybe add +invtsc to qemu args when the 'nonstop_tsc' flag is
requested?
Yep, I could see that as a valid option. If it is visible
in /proc/cpuinfo, then I think that's a compelling reason for
libvirt to model it as a CPU flag too, rather than pretend it
is a new type of timer when it is just an attribute of the
base TSC timer.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|