Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

2016-04-05 Thread Joao Martins
On 04/05/2016 04:12 PM, Jan Beulich wrote: On 05.04.16 at 16:56, wrote: >> On 04/05/2016 11:43 AM, Jan Beulich wrote: >> On 29.03.16 at 15:44, wrote: @@ -541,6 +613,10 @@ static int __init try_platform_timer(struct platform_timesource *pts) if ( rc <= 0 )

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

2016-04-05 Thread Jan Beulich
>>> On 05.04.16 at 16:56, wrote: > On 04/05/2016 11:43 AM, Jan Beulich wrote: > On 29.03.16 at 15:44, wrote: >>> @@ -541,6 +613,10 @@ static int __init try_platform_timer(struct >>> platform_timesource *pts) >>> if ( rc <= 0 ) >>> return rc; >>> >>> +/* We have a platform

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

2016-04-05 Thread Joao Martins
On 04/05/2016 11:43 AM, Jan Beulich wrote: On 29.03.16 at 15:44, wrote: >> Introduce support for using TSC as platform time which is the highest >> resolution time and most performant to get (~20 nsecs). Though there >> are also several problems associated with its usage, and there isn't a >

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

2016-04-05 Thread Jan Beulich
>>> On 29.03.16 at 15:44, wrote: > Introduce support for using TSC as platform time which is the highest > resolution time and most performant to get (~20 nsecs). Though there > are also several problems associated with its usage, and there isn't a > complete (and architecturally defined) guarant

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

2016-04-03 Thread Joao Martins
On 04/01/2016 07:45 PM, Konrad Rzeszutek Wilk wrote: > On Fri, Apr 01, 2016 at 07:38:18PM +0100, Joao Martins wrote: >> [snip] >> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c index ed4ed24..2602dda 100644 --- a/xen/arch/x86/time.c +++ b/xen/arch/x86/time.c @@ -4

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

2016-04-01 Thread Konrad Rzeszutek Wilk
On Fri, Apr 01, 2016 at 07:38:18PM +0100, Joao Martins wrote: > [snip] > > >> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c > >> index ed4ed24..2602dda 100644 > >> --- a/xen/arch/x86/time.c > >> +++ b/xen/arch/x86/time.c > >> @@ -432,6 +432,63 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns) >

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

2016-04-01 Thread Joao Martins
[snip] >> diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c >> index ed4ed24..2602dda 100644 >> --- a/xen/arch/x86/time.c >> +++ b/xen/arch/x86/time.c >> @@ -432,6 +432,63 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns) >> } >> >> /

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

2016-04-01 Thread Konrad Rzeszutek Wilk
On Tue, Mar 29, 2016 at 02:44:08PM +0100, Joao Martins wrote: > Introduce support for using TSC as platform time which is the highest > resolution time and most performant to get (~20 nsecs). Though there > are also several problems associated with its usage, and there isn't a > complete (and arch

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

2016-03-29 Thread Joao Martins
On 03/29/2016 06:39 PM, Konrad Rzeszutek Wilk wrote: >> static void tsc_check_slave(void *unused) >> @@ -1437,6 +1515,20 @@ static int __init verify_tsc_reliability(void) >> } >> } >> >> +if ( !strcmp(opt_clocksource, "tsc") ) > > Pls also update xen-command-line.markdown >

Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

2016-03-29 Thread Konrad Rzeszutek Wilk
> static void tsc_check_slave(void *unused) > @@ -1437,6 +1515,20 @@ static int __init verify_tsc_reliability(void) > } > } > > +if ( !strcmp(opt_clocksource, "tsc") ) Pls also update xen-command-line.markdown > +{ > +if ( try_platform_timer(&plt_tsc) > 0 ) > +

[Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

2016-03-29 Thread Joao Martins
Introduce support for using TSC as platform time which is the highest resolution time and most performant to get (~20 nsecs). Though there are also several problems associated with its usage, and there isn't a complete (and architecturally defined) guarantee that all machines will provide reliable