On Tue, Sep 25, 2012 at 11:08:58AM +0100, Daniel P. Berrange wrote:
On Wed, Sep 12, 2012 at 12:39:39PM -0300, Marcelo Tosatti wrote:
HW TSC scaling is a feature of AMD processors that allows a multiplier to be specified to the TSC frequency exposed to the guest.
KVM also contains provision to trap TSC ("KVM: Infrastructure for software and hardware based TSC rate scaling" cc578287e3224d0da) or advance TSC frequency.
This is useful when migrating to a host with different frequency and the guest is possibly using direct RDTSC instructions for purposes other than measuring cycles (that is, it previously calculated cycles-per-second, and uses that information which is stale after migration).
"qemu-x86: Set tsc_khz in kvm when supported" (e7429073ed1a76518) added support for tsc_khz= option in QEMU.
I am proposing the following changes so that management applications can work with this:
1) New option for tsc_khz, which is tsc_khz=host (QEMU command line option). Host means that QEMU is responsible for retrieving the TSC frequency of the host processor and use that. Management application does not have to deal with the burden.
FYI, libvirt already has support for expressing a number of different TSC related config options, for support of Xen and VMWare's capabilities in this area. What we currently allow for is
<timer name='tsc' frequency='NNN' mode='auto|native|emulate|smpsafe'/>
In this context the frequency attribute provides the HZ value to provide to the guest.
- auto == Emulate if TSC is unstable, else allow native TSC access - native == Always allow native TSC access - emulate = Always emulate TSC - smpsafe == Always emulate TSC, and interlock SMP
These options can be mapped into KVM if necessary (they can map to tsc_khz=XXX or to the module options (unfortunately not per-guest ATM)).
Therefore it appears that this "tsc_khz=auto" option can be specified only if the user specifies so (it can be a per-guest flag hidden in the management configuration/manual).
Sending this email to gather suggestions (or objections) to this interface.
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 :|
Karen had the suggestion to remove the burden of choice from the user, which we can achieve by knowing whether or not the guest is using a paravirtual clock. The problem is that opens a can of races: Did migration happen before or after guest boot process enabled the paravirtual clock etc. I suppose leaving the option to the user is fine: if you run an obscure operating system, which does not support paravirtual clock, then it must be dealt with specialy (its in the manual, no big deal).