| Message ID | 1456193104-12761-7-git-send-email-haozhong.zhang@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> From: Zhang, Haozhong > Sent: Tuesday, February 23, 2016 10:05 AM > > Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>, except: > + > +Hardware TSC Scaling > + > +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read > +by guest rdtsc/p increasing in a different frequency than the host > +TSC frequency. > + > +If a HVM container in default TSC mode (tsc_mode=0) or PVRDTSCP mode 'HVM container' means something different. We usually use "HVM domain" as you may see in other places in this doc. Thanks Kevin
On 02/26/16 12:37, Tian, Kevin wrote: > > From: Zhang, Haozhong > > Sent: Tuesday, February 23, 2016 10:05 AM > > > > Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> > > Reviewed-by: Kevin Tian <kevin.tian@intel.com>, except: > > > + > > +Hardware TSC Scaling > > + > > +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read > > +by guest rdtsc/p increasing in a different frequency than the host > > +TSC frequency. > > + > > +If a HVM container in default TSC mode (tsc_mode=0) or PVRDTSCP mode > > 'HVM container' means something different. We usually use "HVM domain" > as you may see in other places in this doc. > I'll change to 'HVM domain'. Thanks, Haozhong
>>> On 26.02.16 at 05:37, <kevin.tian@intel.com> wrote: >> From: Zhang, Haozhong >> Sent: Tuesday, February 23, 2016 10:05 AM >> >> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> > > Reviewed-by: Kevin Tian <kevin.tian@intel.com>, except: > >> + >> +Hardware TSC Scaling >> + >> +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read >> +by guest rdtsc/p increasing in a different frequency than the host >> +TSC frequency. >> + >> +If a HVM container in default TSC mode (tsc_mode=0) or PVRDTSCP mode > > 'HVM container' means something different. We usually use "HVM domain" > as you may see in other places in this doc. But I think this is specifically meant to refer to both HVM and PVH domains. Jan
On 02/26/16 01:01, Jan Beulich wrote: > >>> On 26.02.16 at 05:37, <kevin.tian@intel.com> wrote: > >> From: Zhang, Haozhong > >> Sent: Tuesday, February 23, 2016 10:05 AM > >> > >> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> > > > > Reviewed-by: Kevin Tian <kevin.tian@intel.com>, except: > > > >> + > >> +Hardware TSC Scaling > >> + > >> +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read > >> +by guest rdtsc/p increasing in a different frequency than the host > >> +TSC frequency. > >> + > >> +If a HVM container in default TSC mode (tsc_mode=0) or PVRDTSCP mode > > > > 'HVM container' means something different. We usually use "HVM domain" > > as you may see in other places in this doc. > > But I think this is specifically meant to refer to both HVM and PVH > domains. > Yes, that is what I mean. So 'HVM container' is the correct name? Haozhong
> From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Friday, February 26, 2016 4:01 PM > > >>> On 26.02.16 at 05:37, <kevin.tian@intel.com> wrote: > >> From: Zhang, Haozhong > >> Sent: Tuesday, February 23, 2016 10:05 AM > >> > >> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> > > > > Reviewed-by: Kevin Tian <kevin.tian@intel.com>, except: > > > >> + > >> +Hardware TSC Scaling > >> + > >> +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read > >> +by guest rdtsc/p increasing in a different frequency than the host > >> +TSC frequency. > >> + > >> +If a HVM container in default TSC mode (tsc_mode=0) or PVRDTSCP mode > > > > 'HVM container' means something different. We usually use "HVM domain" > > as you may see in other places in this doc. > > But I think this is specifically meant to refer to both HVM and PVH > domains. > First, I have a feeling that many people today refer to containers running within a VM as 'VM container', which is a bit confusing to 'HVM container' purpose here. Couldn't we use 'HVM domains' to cover both HVM and PVH (which is PV-HVM)? Curious whether there is formal definition of those terminologies... Second, even when 'HVM container' can be used as you explained, it's inconsistent with other places in same doc, where only 'HVM domain' is used. I'd think consistency is more important in this patch series, and then if 'HVM container' is really preferred which should be a separate patch to update all related docs. Thanks Kevin
On 02/29/16 10:02, Tian, Kevin wrote: > > From: Jan Beulich [mailto:JBeulich@suse.com] > > Sent: Friday, February 26, 2016 4:01 PM > > > > >>> On 26.02.16 at 05:37, <kevin.tian@intel.com> wrote: > > >> From: Zhang, Haozhong > > >> Sent: Tuesday, February 23, 2016 10:05 AM > > >> > > >> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> > > > > > > Reviewed-by: Kevin Tian <kevin.tian@intel.com>, except: > > > > > >> + > > >> +Hardware TSC Scaling > > >> + > > >> +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read > > >> +by guest rdtsc/p increasing in a different frequency than the host > > >> +TSC frequency. > > >> + > > >> +If a HVM container in default TSC mode (tsc_mode=0) or PVRDTSCP mode > > > > > > 'HVM container' means something different. We usually use "HVM domain" > > > as you may see in other places in this doc. > > > > But I think this is specifically meant to refer to both HVM and PVH > > domains. > > > > First, I have a feeling that many people today refer to containers > running within a VM as 'VM container', which is a bit confusing to > 'HVM container' purpose here. Couldn't we use 'HVM domains' > to cover both HVM and PVH (which is PV-HVM)? Curious whether > there is formal definition of those terminologies... > I call it 'HVM container' because I use has_hvm_container_domain(d) | #define has_hvm_container_domain(d) ((d)->guest_type != guest_type_pv) to check whether TSC scaling can be used by a domain, which, in current implementation, is either a HVM domain (d->guest_type == guest_type_hvm) or a PVH domain (d->guest_type == guest_type_pvh). And I also noticed another macro is_hvm_domain(d) | #define is_hvm_domain(d) ((d)->guest_type == guest_type_hvm) so I think 'HVM domain' can not be used to refer to both HVM and PVH domains. > Second, even when 'HVM container' can be used as you explained, > it's inconsistent with other places in same doc, where only 'HVM > domain' is used. I'd think consistency is more important in this > patch series, and then if 'HVM container' is really preferred which > should be a separate patch to update all related docs. > Or, maybe I should make it explicit, i.e. using 'HVM and PVH domains' rather than 'HVM container'. Haozhong
>>> On 29.02.16 at 03:45, <haozhong.zhang@intel.com> wrote: > On 02/29/16 10:02, Tian, Kevin wrote: >> > From: Jan Beulich [mailto:JBeulich@suse.com] >> > Sent: Friday, February 26, 2016 4:01 PM >> > >> > >>> On 26.02.16 at 05:37, <kevin.tian@intel.com> wrote: >> > >> From: Zhang, Haozhong >> > >> Sent: Tuesday, February 23, 2016 10:05 AM >> > >> >> > >> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> >> > > >> > > Reviewed-by: Kevin Tian <kevin.tian@intel.com>, except: >> > > >> > >> + >> > >> +Hardware TSC Scaling >> > >> + >> > >> +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read >> > >> +by guest rdtsc/p increasing in a different frequency than the host >> > >> +TSC frequency. >> > >> + >> > >> +If a HVM container in default TSC mode (tsc_mode=0) or PVRDTSCP mode >> > > >> > > 'HVM container' means something different. We usually use "HVM domain" >> > > as you may see in other places in this doc. >> > >> > But I think this is specifically meant to refer to both HVM and PVH >> > domains. >> > >> >> First, I have a feeling that many people today refer to containers >> running within a VM as 'VM container', which is a bit confusing to >> 'HVM container' purpose here. Couldn't we use 'HVM domains' >> to cover both HVM and PVH (which is PV-HVM)? Curious whether >> there is formal definition of those terminologies... >> > > I call it 'HVM container' because I use has_hvm_container_domain(d) > | #define has_hvm_container_domain(d) ((d)->guest_type != guest_type_pv) > to check whether TSC scaling can be used by a domain, which, in current > implementation, is either a HVM domain (d->guest_type == guest_type_hvm) > or a PVH domain (d->guest_type == guest_type_pvh). > > And I also noticed another macro is_hvm_domain(d) > | #define is_hvm_domain(d) ((d)->guest_type == guest_type_hvm) > so I think 'HVM domain' can not be used to refer to both HVM and PVH > domains. Indeed. >> Second, even when 'HVM container' can be used as you explained, >> it's inconsistent with other places in same doc, where only 'HVM >> domain' is used. I'd think consistency is more important in this >> patch series, and then if 'HVM container' is really preferred which >> should be a separate patch to update all related docs. Yes, inconsistencies in the docs are likely a result of them not having got updated when PVH got introduced, of PVH existence being neglected at the time they got put in. > Or, maybe I should make it explicit, i.e. using 'HVM and PVH domains' > rather than 'HVM container'. That's an option, but personally I think a worse one than the "HVM container" term. Jan
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 40690bd..56b1117 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -1313,9 +1313,17 @@ deprecated. Options are: =item B<"default"> -Guest rdtsc/p executed natively when monotonicity can be guaranteed +Guest rdtsc/p is executed natively when monotonicity can be guaranteed and emulated otherwise (with frequency scaled if necessary). +If a HVM container in B<default> TSC mode is created on a host that +provides constant host TSC, its guest TSC frequency will be the same +as the host. If it is later migrated to another host that provide +constant host TSC and supports Intel VMX TSC scaling/AMD SVM TSC +ratio, its guest TSC frequency will be the same before and after +migration, and guest rdtsc/p will be executed natively as well after +migration. + =item B<"always_emulate"> Guest rdtsc/p always emulated at 1GHz (kernel and user). Guest rdtsc/p @@ -1337,6 +1345,10 @@ determine when a restore/migration has occurred and assumes guest obtains/uses pvclock-like mechanism to adjust for monotonicity and frequency changes. +If a HVM container in B<native_paravirt> TSC mode can execute both guest +rdtsc and guest rdtscp natively, then the guest TSC frequency will be +determined in the similar way to that of B<default> TSC mode. + =back Please see F<docs/misc/tscmode.txt> for more information on this option. diff --git a/docs/misc/tscmode.txt b/docs/misc/tscmode.txt index e8c84e8..01ee060 100644 --- a/docs/misc/tscmode.txt +++ b/docs/misc/tscmode.txt @@ -297,3 +297,24 @@ and also much faster than nearly all OS-provided time mechanisms. While pvrtscp is too complex for most apps, certain enterprise TSC-sensitive high-TSC-frequency apps may find it useful to obtain a significant performance gain. + +Hardware TSC Scaling + +Intel VMX TSC scaling and AMD SVM TSC ratio allow the guest TSC read +by guest rdtsc/p increasing in a different frequency than the host +TSC frequency. + +If a HVM container in default TSC mode (tsc_mode=0) or PVRDTSCP mode +(tsc_mode=3) is created on a host that provides constant TSC, its +guest TSC frequency will be the same as the host. If it is later +migrated to another host that provides constant TSC and supports Intel +VMX TSC scaling/AMD SVM TSC ratio, its guest TSC frequency will be the +same before and after migration. + +For above HVM container in default TSC mode (tsc_mode=0), if above +hosts support rdtscp, both guest rdtsc and rdtscp instructions will be +executed natively before and after migration. + +For above HVM container in PVRDTSCP mode (tsc_mode=3), if the +destination host does not support rdtscp, the guest rdtscp instruction +will be emulated with the guest TSC frequency.
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> --- docs/man/xl.cfg.pod.5 | 14 +++++++++++++- docs/misc/tscmode.txt | 21 +++++++++++++++++++++ 2 files changed, 34 insertions(+), 1 deletion(-)