Re: [Xen-devel] [PATCH 13/13] tools/libxl: Add 'vtsc_khz' option to set guest TSC rate

[Haozhong Zhang <haozhong.zhang@xxxxxxxxx>]

On Tue, Sep 29, 2015 at 03:37:06PM +0100, Ian Campbell wrote:
> On Tue, 2015-09-29 at 22:01 +0800, Haozhong Zhang wrote:
> > On Tue, Sep 29, 2015 at 02:56:12PM +0100, Andrew Cooper wrote:
> > > On 29/09/15 14:53, Haozhong Zhang wrote:
> > > > On Tue, Sep 29, 2015 at 11:28:38AM +0100, Ian Campbell wrote:
> > > > > On Tue, 2015-09-29 at 11:24 +0100, Andrew Cooper wrote:
> > > > > > On 29/09/15 11:13, Haozhong Zhang wrote:
> > > > > > > On Tue, Sep 29, 2015 at 11:04:14AM +0100, Ian Campbell wrote:
> > > > > > > > On Mon, 2015-09-28 at 15:13 +0800, Haozhong Zhang wrote:
> > > > > > > > > This patch adds an option 'vtsc_khz' to allow users to set
> > > > > > > > > vcpu's
> > > > > > > > > TSC
> > > > > > > > > rate in KHz. In the case that tsc_mode = 'default', the
> > > > > > > > > default
> > > > > > > > > value of
> > > > > > > > > 'vtsc_khz' option is the host TSC rate which is used when
> > > > > > > > > 'vtsc_khz'
> > > > > > > > > option is set to 0 or does not appear in the configuration.
> > > > > > > > > In all
> > > > > > > > > other
> > > > > > > > > cases of tsc_mode, 'vtsc_khz' option is just ignored.
> > > > > > > > > 
> > > > > > > > > Another purpose of adding this option is to keep vcpu's TSC
> > > > > > > > > rate
> > > > > > > > > across
> > > > > > > > > guest reboot. In existing code, a new domain is created
> > > > > > > > > from the
> > > > > > > > > configuration of the previous domain which was just
> > > > > > > > > rebooted.
> > > > > > > > > vcpu's TSC
> > > > > > > > > rate is not stored in the configuration and the host TSC
> > > > > > > > > rate is
> > > > > > > > > the
> > > > > > > > > used as vcpu's TSC rate. This works fine unless the
> > > > > > > > > previous domain
> > > > > > > > > was
> > > > > > > > > migrated from another host machine with a different host
> > > > > > > > > TSC rate
> > > > > > > > > than
> > > > > > > > > the current one.
> > > > > > > > I understand why this is necessary over a migration, but why
> > > > > > > > is it
> > > > > > > > important to be able to retain the TSC rate across a reboot?
> > > > > > > > What is
> > > > > > > > the
> > > > > > > > usecase there?
> > > > > > > > 
> > > > > > > No usecase so far. Is 'making a virtual machine more like a
> > > > > > > physical
> > > > > > > machine' reasonable here? (I suppose a physical machine retains
> > > > > > > TSC
> > > > > > > rate across reboot)
> > > > > > There are situations such as altering firmware settings which can
> > > > > > cause
> > > > > > the TSC rate to differ across reboot.  I don't see any reason to
> > > > > > try and
> > > > > > maintain it across VM reboots.
> > > > > Right. If it happens to come for free as a side effect of making it
> > > > > work
> > > > > for migration then fine.
> > > > > 
> > > > > But it seems to me that tsc rate could/should be in the hypervisors
> > > > > save
> > > > > blob and require no interaction with the toolstack once it is
> > > > > latched when
> > > > > the domain is built.
> > > > > 
> > > > > Ian.
> > > > > 
> > > > Seemingly I don't need vtsc_khz at all if retaining tsc rate across
> > > > reboot is unnecessary (or even wrong). The migration of tsc rate is
> > > > already done through write_tsc_info() and handle_tsc_info() w/o this
> > > > patch. I'll check if "xl save/restore" also go through this path. If
> > > > so, I think vtsc_khz can be removed.
> > > 
> > > I can confirm from my rewrite of migration that tsc info is explicitly
> > > saved and restored in both PV and HVM migration.
> > > 
> > 
> > Great! Thanks!
> 
> In which case unless someone has a concrete use case for manual
> configuration of the tsc rate I guess I'll expect a v2 with no tools side
> in it.
>

This last patch should not be needed in v2.

> Ian.
> 
> > 
> > - Haozhong
> > 
> > > ~Andrew
> > > 
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxx
> > > http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel