Re: [PATCH v5 6/6] docs: Add descriptions of TSC scaling in xl.cfg and tscmode.txt

From: "Jan Beulich" <JBeulich@suse.com>
To: Haozhong Zhang <haozhong.zhang@intel.com>,
	Kevin Tian <kevin.tian@intel.com>
Cc: Keir Fraser <keir@xen.org>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v5 6/6] docs: Add descriptions of TSC scaling in xl.cfg and tscmode.txt
Date: Mon, 29 Feb 2016 02:04:12 -0700	[thread overview]
Message-ID: <56D4179C02000078000D7205@prv-mh.provo.novell.com> (raw)
In-Reply-To: <20160229024537.GA28073@hz-desktop.sh.intel.com>

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

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