public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: libvir-list@redhat.com, kvm <kvm@vger.kernel.org>
Subject: TSC scaling interface to management
Date: Wed, 12 Sep 2012 12:39:39 -0300	[thread overview]
Message-ID: <20120912153939.GA19144@amt.cnet> (raw)



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.

2) New subsection with tsc_khz value. Destination host should consult 
supported features of running kernel and fail if feature is unsupported. 


It is not necessary to use this tsc_khz setting with modern guests
using paravirtual clocks, or when its known that applications make 
proper use of the time interface provided by operating systems.

On the other hand, legacy applications or setups which require no 
modification and correct operation while virtualized and make
use of RDTSC might need this.

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.


             reply	other threads:[~2012-09-12 15:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-12 15:39 Marcelo Tosatti [this message]
2012-09-20 21:02 ` [libvirt] TSC scaling interface to management Dor Laor
2012-09-21  2:51   ` Marcelo Tosatti
2012-09-21 20:30     ` Dor Laor
2012-09-23  2:06       ` Marcelo Tosatti
2012-09-23 13:41         ` Dor Laor
2012-09-25 10:08 ` Daniel P. Berrange
2012-09-29  1:07   ` Marcelo Tosatti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120912153939.GA19144@amt.cnet \
    --to=mtosatti@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=libvir-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox