[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 13/13] tools/libxl: Add 'vtsc_khz' option to set guest TSC rate
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. - Haozhong > _______________________________________________ > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |