Re: [Xen-devel] [PATCH v2 00/14] Add VMX TSC scaling support

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 11/12/15 07:35, Tian, Kevin wrote:
>> From: Zhang, Haozhong
>> Sent: Thursday, December 10, 2015 7:13 PM
>>
>> On 12/10/15 10:43, Tian, Kevin wrote:
>>>> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
>>>> Sent: Tuesday, December 08, 2015 1:04 AM
>>>>
>>>> On 07/12/15 10:16, Haozhong Zhang wrote:
>>>>> On 12/07/15 10:03, Egger, Christoph wrote:
>>>>>> Did you consider nested virtualization?
>>>>>> L1 hypervisor may have a different tsc scaling
>>>>>> and L2 guest again may have a different tsc scale ratio.
>>>>>>
>>>>> Oh, I forgot this. I'll check the nested TSC scaling code (mostly
>>>>> about nested SVM TSC ratio, because this patch series does not expose
>>>>> VMX TSC scaling to L1 guest).
>>>>>
>>>>> BTW, are there any practical usage scenarios of nested TSC scaling? If
>>>>> any, I may also need to consider adding nested virtualization support
>>>>> to VMX TSC scaling.
>>>> I would say that there are genuine uses for nested TSC scaling.  An L1
>>>> hypervisor is going to want to scale for the same reasons as the L0
>>>> hypervisor.
>>>>
>>>> Having said that, if TSC scaling is correctly hidden from the L1 guests,
>>>> I would advise against conflating the two issues together.  i.e. getting
>>>> nested TSC scaling working is not a prerequisite for accepting this series.
>>>>
>>> Why is nested TSC scaling even an issue? If L0 hypervisors cross hosts
>>> can always guarantee constant TSC frequency through TSC scaling, L1
>>> hypervisor will never see inconstant TSC frequency so why bother to
>>> expose TSC scaling at all?
>>>
>> If exposing TSC scaling to L1, then L0 hypervisor will need to adapt
>> the TSC scaling ratio set by L1 hypervisor, which has not been done by
>> this patch series.
>>
>> Consider an example that the host TSC frequency is freq_0 and
>> 1. L0 Xen sets TSC scaling ratio to a non-identical one ratio_0.
>>
>> 2. Then L1 hypervisor will observe a "host" TSC frequency (freq_0 * ratio_0).
>>
>> 3. If L1 hypervisor sets a TSC scaling ratio ratio_1, it intends to
>>    provide a guest TSC frequency (freq_0 * ratio_0 * ratio_1).
>>
>>    However, if ratio_1 is directly written into nested VMCS that is
>>    later applied to the host CPU, then the L2 guest will get an
>>    incorrect guest TSC frequency (freq_0 * ratio_1).
>>
>>
> My point is why we need expose TSC scaling to L1, if L0 has ensures
> constant TSC w/ TSC scaling ratio...

Because a set of L1 hypervisors might want to migrate VMs between them.

Or a more interesting setup migrating VMs between L0 and L1
hypervisors.  (I tried this once and it didn't blow up)

Once constant TSC has been advertised to a guest, any future hypervisor
it might find itself on must be able to guarantee to provide the same
frequency.

~Andrew

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