From: "Daniel P. Berrange" <berrange@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: libvir-list@redhat.com, kvm <kvm@vger.kernel.org>
Subject: Re: [libvirt] TSC scaling interface to management
Date: Tue, 25 Sep 2012 11:08:58 +0100 [thread overview]
Message-ID: <20120925100858.GA5869@redhat.com> (raw)
In-Reply-To: <20120912153939.GA19144@amt.cnet>
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
> 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 :|
next prev parent reply other threads:[~2012-09-25 10:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 15:39 TSC scaling interface to management Marcelo Tosatti
2012-09-20 21:02 ` [libvirt] " 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 [this message]
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=20120925100858.GA5869@redhat.com \
--to=berrange@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=libvir-list@redhat.com \
--cc=mtosatti@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.