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).
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
