RE: [Xen-devel] RE: Saving/Restoring IA32_TSC_AUX MSR

["Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>]

Hi, Dan, 
        I am now trying to add the rdtscp support for Xen HVM guest. 
        I have some questions about your pvrdtscp patch. See below. 

Dan Magenheimer wrote:
> Hi Jun --
> 
>> But it's possible that multiple domains use the pvrdtscp
>> algorithm, and the incarnation number is domain specific.
> 
> OK, I see.  The code for writing TSC_AUX is in
> __update_vcpu_system_time() not in context switch.

Will you modify the place where Hypervisor writes TSC_AUX MSR? 
In the current pvrdtscp logic, I think this MSR should be written while
vcpu context switch. Also, this will make HVM support much easier 
because that MSR would not be modified by Hypervisor time to time.

> 
>> We also have the issue when adding RDTSCP support for
>> HVM guests.
> 
> Only if you expose the rdtscp bit via cpuid.  This could
> certainly be done but, as I said, is probably pointless.
> (The pvrdtscp algorithm uses the instruction whether or
> not the rdtscp bit is set in cpuid, since Xen emulates
> it -- for PV domains only now -- if the physical machine
> doesn't support the instruction.

We are planning to add HVM support for RDTSCP, and the behavior for this 
instruction
will follow the native way. 
This caused a problem that RDTSCP instruction in application has different 
experience
upon PV and HVM domains. Do you have any comment about this? Thanks!

Thanks!
Dongxiao

> 
> Dan
> 
>> -----Original Message-----
>> From: Nakajima, Jun [mailto:jun.nakajima@xxxxxxxxx]
>> Sent: Wednesday, December 09, 2009 10:08 AM
>> To: Dan Magenheimer; xen-devel@xxxxxxxxxxxxxxxxxxx
>> Subject: RE: Saving/Restoring IA32_TSC_AUX MSR
>> 
>> 
>> Dan Magenheimer wrote on Wed, 9 Dec 2009 at 08:59:59:
>> 
>>> Hi Jun --
>>> 
>> 
>> Dan,
>> 
>>> Xen doesn't expose the TSC rdtscp bit so assumes that
>>> no guests depend on it.  So no save/restore of TSC_AUX
>>> is necessary.  Xen could provide support for the TSC
>> 
>> But it's possible that multiple domains use the pvrdtscp
>> algorithm, and the incarnation number is domain specific. We
>> also have the issue when adding RDTSCP support for HVM guests.
>> 
>>> rdtscp bit and allow a guest OS to manage TSC_AUX, but
>>> the existing use of TSC_AUX by Linux would fail to
>>> provide the desired result across migration, so there's
>>> little point.  Also the pvrdtscp algorithm now assumes
>>> that Xen itself is responsible for updating TSC_AUX
>>> whenever a migration (across physical machines) occurs.
>>> 
>>> The #define for write_rdtscp_aux is from Linux source,
>>> so I didn't change the code and define the constant.
>>> 
>>> Dan
>>> 
>>>> -----Original Message-----
>>>> From: Nakajima, Jun [mailto:jun.nakajima@xxxxxxxxx]
>>>> Sent: Wednesday, December 09, 2009 9:42 AM
>>>> To: xen-devel@xxxxxxxxxxxxxxxxxxx
>>>> Cc: Dan Magenheimer
>>>> Subject: Saving/Restoring IA32_TSC_AUX MSR
>>>> 
>>>> 
>>>> I see the code like (in arch/x86/time.c), and wondering how
>>>> IA32_TSC_AUX MSR is saved/restored at domain switch time.
>>>> 
>>>>     if ( (d->arch.tsc_mode ==  TSC_MODE_PVRDTSCP) &&
>>>>          boot_cpu_has(X86_FEATURE_RDTSCP) )
>>>>         write_rdtscp_aux(d->arch.incarnation);
>>>> 
>>>> BTW,
>>>> 
>>>> include/asm-x86/msr.h
>>>> #define write_rdtscp_aux(val) wrmsr(0xc0000103, (val), 0)
>>>> 
>>>> We should write like wrmsr(MSR_TSC_AUX, (val), 0) by adding
>>>> +#define MSR_TSC_AUX               0xc0000103 /* Auxiliary TSC */
>>>> in include/asm-x86/msr-index.h
>>>> 
>>>> Thanks,
>>>> Jun
>>>> ---
>>>> Intel Open Source Technology Center
>>>> 
>>>> 
>> 
>> Jun
>> ___
>> Intel Open Source Technology Center
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel