Re: [libvirt] TSC scaling interface to management

[Marcelo Tosatti <mtosatti@redhat.com>]

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).