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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.02.16 at 03:45, <haozhong.zhang@xxxxxxxxx> wrote:
> On 02/29/16 10:02, Tian, Kevin wrote:
>> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> > Sent: Friday, February 26, 2016 4:01 PM
>> > 
>> > >>> On 26.02.16 at 05:37, <kevin.tian@xxxxxxxxx> wrote:
>> > >>  From: Zhang, Haozhong
>> > >> Sent: Tuesday, February 23, 2016 10:05 AM
>> > >>
>> > >> Signed-off-by: Haozhong Zhang <haozhong.zhang@xxxxxxxxx>
>> > >
>> > > Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>, 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel