>>> On 24.08.16 at 14:43, <joao.m.mart...@oracle.com> wrote:
> And use to initialize platform time solely for clocksource=tsc,
> as opposed to initializing platform overflow timer, which would
> only fire in ~180 years (on 2.2 Ghz Broadwell processor).

Do we really want to risk this time period going down by two orders
of magnitude? Is there anything that's really expensive in setting the
overflow timer in the far distant future?

> Changes since v2:
>  - Remove pointless intializer and replace it with the
>  platform_time init return.

Does this really apply to this patch?

> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -526,17 +526,31 @@ static s_time_t __read_platform_stime(u64 
> platform_time)
>      return (stime_platform_stamp + scale_delta(diff, &plt_scale));
>  }
>  
> +static void __plt_update(void)

A single leading underscore only, please.

> @@ -630,10 +644,21 @@ static s64 __init try_platform_timer(struct 
> platform_timesource *pts)
>  
>      set_time_scale(&plt_scale, pts->frequency);
>  
> -    plt_overflow_period = scale_delta(
> -        1ull << (pts->counter_bits - 1), &plt_scale);
>      plt_src = *pts;
>  
> +    if ( pts == &plt_tsc )
> +    {
> +        plt_update();
> +    }

Unnecessary braces.

Jan


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

Reply via email to