On 02/23/16 08:37, Jan Beulich wrote: > >>> On 23.02.16 at 15:16, <boris.ostrov...@oracle.com> wrote: > > On 02/23/2016 09:10 AM, Jan Beulich wrote: > >>>>> On 23.02.16 at 15:00, <boris.ostrov...@oracle.com> wrote: > >>> On 02/22/2016 09:04 PM, Haozhong Zhang wrote: > >>> > >>>> > >>>> + if ( cpu_has_tsc_ratio ) > >>>> + svm_function_table.tsc_scaling.ratio_frac_bits = 32; > >>>> + > >>> > >>>> > >>>> +#define hvm_tsc_scaling_supported \ > >>>> + (!!hvm_funcs.tsc_scaling.ratio_frac_bits) > >>>> + > >>> What is the difference (in usage) between cpu_has_tsc_ratio and > >>> hvm_tsc_scaling_supported? Isn't the first imply the second (and if yes > >>> then what's the reason for having the latter)? > >> Iiuc cpu_has_tsc_ratio is AMD/SVM specific, while > >> hvm_tsc_scaling_supported is meant to be vendor independent. > >
Yes, it's to be vendor independent. Earlier versions of this patch series set a field tsc_scaling_supported in hvm_function_table if cpu_has_vmx_tsc_scaling or cpu_has_tsc_ratio. Jan suggested we could get the same information if some of other fields are initialized conditionally, and no extra field (tsc_scaling_supported) would be needed any more. > > Ah, OK. Can we then > > > > #define hvm_tsc_scaling_supported (cpu_has_vmx_tsc_scaling || > > cpu_has_tsc_ratio) > > Why would we? The above is doing precisely (but implicitly) that, > just with only one memory access instead of two. > Boris, does the current one look fine for you, as it does the same thing as your suggested one? Thanks, Haozhong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
