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 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!

- 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