Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-23 Thread Jan Kiszka
On 2017-11-23 19:36, Thomas Gleixner wrote:
> On Mon, 20 Nov 2017, Jan Kiszka wrote:
>> On 2017-11-20 12:24, Thomas Gleixner wrote:
>>> On Sat, 18 Nov 2017, Jan Kiszka wrote:
 On 2017-11-17 23:49, Thomas Gleixner wrote:
> On Thu, 16 Nov 2017, Jan Kiszka wrote:
>> Calibrate the TSC and, where necessary, the APIC timer against the
>> TMTIMER. We need our own implementation as neither the PIC nor the HPET
>> are available, and the standard calibration routines try to make use of
>> them.
>
> Why is this needed at all?
>
> The host the frequency already. So this can be done w/o pmtimer and extra
> calibration routine.

 The hypervisor does not have the frequencies. It will never use the APIC
 timer (it's owned by the guests), and it has no use case for the TSC so
 far. Only the root cell (the Linux that booted the system) has that
 data. Now we could

 - trust the root cell to provide the right values and export them during
   startup to the hypervisor and from there to the non-root cells.

 - calculate the frequencies once and store them in the hyperivsor
   config, just like other system-specific information, for re-export to
   the cells.

 But I don't think option 1 will be ok for all use cases. Maybe a
 combination of both, falling back to the root cell data if nothing is
 defined in the config. Let me think about this.
>>>
>>> Another question is whether systems which can support jailhouse, have the
>>> frequencies available via cpuid/msr and can avoid that calibration thing
>>> completely.
>>
>> OK, some may (not Xeons, though), and we would not exploit it with this
>> approach.
> 
> Ok. Let's expose pmtimer it's not a big issue.

I think PM timer should to be exposed independently of the question
wheather calibrate or not. If - for whatever reason - TSC is/becomes
unstable, we should have a fallback clock.

I've started to hack on forwarding calibration results from (primary)
Linux to the other guests with the option to alternatively hard-code the
values in the configuration. Seems to work find, just requires to export
lapic_timer_frequency. I'll push updates the next days that exploit this
and simplifies this patch.

Jan


Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-23 Thread Jan Kiszka
On 2017-11-23 19:36, Thomas Gleixner wrote:
> On Mon, 20 Nov 2017, Jan Kiszka wrote:
>> On 2017-11-20 12:24, Thomas Gleixner wrote:
>>> On Sat, 18 Nov 2017, Jan Kiszka wrote:
 On 2017-11-17 23:49, Thomas Gleixner wrote:
> On Thu, 16 Nov 2017, Jan Kiszka wrote:
>> Calibrate the TSC and, where necessary, the APIC timer against the
>> TMTIMER. We need our own implementation as neither the PIC nor the HPET
>> are available, and the standard calibration routines try to make use of
>> them.
>
> Why is this needed at all?
>
> The host the frequency already. So this can be done w/o pmtimer and extra
> calibration routine.

 The hypervisor does not have the frequencies. It will never use the APIC
 timer (it's owned by the guests), and it has no use case for the TSC so
 far. Only the root cell (the Linux that booted the system) has that
 data. Now we could

 - trust the root cell to provide the right values and export them during
   startup to the hypervisor and from there to the non-root cells.

 - calculate the frequencies once and store them in the hyperivsor
   config, just like other system-specific information, for re-export to
   the cells.

 But I don't think option 1 will be ok for all use cases. Maybe a
 combination of both, falling back to the root cell data if nothing is
 defined in the config. Let me think about this.
>>>
>>> Another question is whether systems which can support jailhouse, have the
>>> frequencies available via cpuid/msr and can avoid that calibration thing
>>> completely.
>>
>> OK, some may (not Xeons, though), and we would not exploit it with this
>> approach.
> 
> Ok. Let's expose pmtimer it's not a big issue.

I think PM timer should to be exposed independently of the question
wheather calibrate or not. If - for whatever reason - TSC is/becomes
unstable, we should have a fallback clock.

I've started to hack on forwarding calibration results from (primary)
Linux to the other guests with the option to alternatively hard-code the
values in the configuration. Seems to work find, just requires to export
lapic_timer_frequency. I'll push updates the next days that exploit this
and simplifies this patch.

Jan


Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-23 Thread Thomas Gleixner
On Mon, 20 Nov 2017, Jan Kiszka wrote:
> On 2017-11-20 12:24, Thomas Gleixner wrote:
> > On Sat, 18 Nov 2017, Jan Kiszka wrote:
> >> On 2017-11-17 23:49, Thomas Gleixner wrote:
> >>> On Thu, 16 Nov 2017, Jan Kiszka wrote:
>  Calibrate the TSC and, where necessary, the APIC timer against the
>  TMTIMER. We need our own implementation as neither the PIC nor the HPET
>  are available, and the standard calibration routines try to make use of
>  them.
> >>>
> >>> Why is this needed at all?
> >>>
> >>> The host the frequency already. So this can be done w/o pmtimer and extra
> >>> calibration routine.
> >>
> >> The hypervisor does not have the frequencies. It will never use the APIC
> >> timer (it's owned by the guests), and it has no use case for the TSC so
> >> far. Only the root cell (the Linux that booted the system) has that
> >> data. Now we could
> >>
> >> - trust the root cell to provide the right values and export them during
> >>   startup to the hypervisor and from there to the non-root cells.
> >>
> >> - calculate the frequencies once and store them in the hyperivsor
> >>   config, just like other system-specific information, for re-export to
> >>   the cells.
> >>
> >> But I don't think option 1 will be ok for all use cases. Maybe a
> >> combination of both, falling back to the root cell data if nothing is
> >> defined in the config. Let me think about this.
> > 
> > Another question is whether systems which can support jailhouse, have the
> > frequencies available via cpuid/msr and can avoid that calibration thing
> > completely.
> 
> OK, some may (not Xeons, though), and we would not exploit it with this
> approach.

Ok. Let's expose pmtimer it's not a big issue.

Thanks,

tglx


Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-23 Thread Thomas Gleixner
On Mon, 20 Nov 2017, Jan Kiszka wrote:
> On 2017-11-20 12:24, Thomas Gleixner wrote:
> > On Sat, 18 Nov 2017, Jan Kiszka wrote:
> >> On 2017-11-17 23:49, Thomas Gleixner wrote:
> >>> On Thu, 16 Nov 2017, Jan Kiszka wrote:
>  Calibrate the TSC and, where necessary, the APIC timer against the
>  TMTIMER. We need our own implementation as neither the PIC nor the HPET
>  are available, and the standard calibration routines try to make use of
>  them.
> >>>
> >>> Why is this needed at all?
> >>>
> >>> The host the frequency already. So this can be done w/o pmtimer and extra
> >>> calibration routine.
> >>
> >> The hypervisor does not have the frequencies. It will never use the APIC
> >> timer (it's owned by the guests), and it has no use case for the TSC so
> >> far. Only the root cell (the Linux that booted the system) has that
> >> data. Now we could
> >>
> >> - trust the root cell to provide the right values and export them during
> >>   startup to the hypervisor and from there to the non-root cells.
> >>
> >> - calculate the frequencies once and store them in the hyperivsor
> >>   config, just like other system-specific information, for re-export to
> >>   the cells.
> >>
> >> But I don't think option 1 will be ok for all use cases. Maybe a
> >> combination of both, falling back to the root cell data if nothing is
> >> defined in the config. Let me think about this.
> > 
> > Another question is whether systems which can support jailhouse, have the
> > frequencies available via cpuid/msr and can avoid that calibration thing
> > completely.
> 
> OK, some may (not Xeons, though), and we would not exploit it with this
> approach.

Ok. Let's expose pmtimer it's not a big issue.

Thanks,

tglx


Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-20 Thread Jan Kiszka
On 2017-11-20 12:24, Thomas Gleixner wrote:
> On Sat, 18 Nov 2017, Jan Kiszka wrote:
>> On 2017-11-17 23:49, Thomas Gleixner wrote:
>>> On Thu, 16 Nov 2017, Jan Kiszka wrote:
 Calibrate the TSC and, where necessary, the APIC timer against the
 TMTIMER. We need our own implementation as neither the PIC nor the HPET
 are available, and the standard calibration routines try to make use of
 them.
>>>
>>> Why is this needed at all?
>>>
>>> The host the frequency already. So this can be done w/o pmtimer and extra
>>> calibration routine.
>>
>> The hypervisor does not have the frequencies. It will never use the APIC
>> timer (it's owned by the guests), and it has no use case for the TSC so
>> far. Only the root cell (the Linux that booted the system) has that
>> data. Now we could
>>
>> - trust the root cell to provide the right values and export them during
>>   startup to the hypervisor and from there to the non-root cells.
>>
>> - calculate the frequencies once and store them in the hyperivsor
>>   config, just like other system-specific information, for re-export to
>>   the cells.
>>
>> But I don't think option 1 will be ok for all use cases. Maybe a
>> combination of both, falling back to the root cell data if nothing is
>> defined in the config. Let me think about this.
> 
> Another question is whether systems which can support jailhouse, have the
> frequencies available via cpuid/msr and can avoid that calibration thing
> completely.

OK, some may (not Xeons, though), and we would not exploit it with this
approach.

Jan


Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-20 Thread Jan Kiszka
On 2017-11-20 12:24, Thomas Gleixner wrote:
> On Sat, 18 Nov 2017, Jan Kiszka wrote:
>> On 2017-11-17 23:49, Thomas Gleixner wrote:
>>> On Thu, 16 Nov 2017, Jan Kiszka wrote:
 Calibrate the TSC and, where necessary, the APIC timer against the
 TMTIMER. We need our own implementation as neither the PIC nor the HPET
 are available, and the standard calibration routines try to make use of
 them.
>>>
>>> Why is this needed at all?
>>>
>>> The host the frequency already. So this can be done w/o pmtimer and extra
>>> calibration routine.
>>
>> The hypervisor does not have the frequencies. It will never use the APIC
>> timer (it's owned by the guests), and it has no use case for the TSC so
>> far. Only the root cell (the Linux that booted the system) has that
>> data. Now we could
>>
>> - trust the root cell to provide the right values and export them during
>>   startup to the hypervisor and from there to the non-root cells.
>>
>> - calculate the frequencies once and store them in the hyperivsor
>>   config, just like other system-specific information, for re-export to
>>   the cells.
>>
>> But I don't think option 1 will be ok for all use cases. Maybe a
>> combination of both, falling back to the root cell data if nothing is
>> defined in the config. Let me think about this.
> 
> Another question is whether systems which can support jailhouse, have the
> frequencies available via cpuid/msr and can avoid that calibration thing
> completely.

OK, some may (not Xeons, though), and we would not exploit it with this
approach.

Jan


Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-20 Thread Thomas Gleixner
On Sat, 18 Nov 2017, Jan Kiszka wrote:
> On 2017-11-17 23:49, Thomas Gleixner wrote:
> > On Thu, 16 Nov 2017, Jan Kiszka wrote:
> >> Calibrate the TSC and, where necessary, the APIC timer against the
> >> TMTIMER. We need our own implementation as neither the PIC nor the HPET
> >> are available, and the standard calibration routines try to make use of
> >> them.
> > 
> > Why is this needed at all?
> > 
> > The host the frequency already. So this can be done w/o pmtimer and extra
> > calibration routine.
> 
> The hypervisor does not have the frequencies. It will never use the APIC
> timer (it's owned by the guests), and it has no use case for the TSC so
> far. Only the root cell (the Linux that booted the system) has that
> data. Now we could
> 
> - trust the root cell to provide the right values and export them during
>   startup to the hypervisor and from there to the non-root cells.
> 
> - calculate the frequencies once and store them in the hyperivsor
>   config, just like other system-specific information, for re-export to
>   the cells.
> 
> But I don't think option 1 will be ok for all use cases. Maybe a
> combination of both, falling back to the root cell data if nothing is
> defined in the config. Let me think about this.

Another question is whether systems which can support jailhouse, have the
frequencies available via cpuid/msr and can avoid that calibration thing
completely.

Thanks,

tglx


Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-20 Thread Thomas Gleixner
On Sat, 18 Nov 2017, Jan Kiszka wrote:
> On 2017-11-17 23:49, Thomas Gleixner wrote:
> > On Thu, 16 Nov 2017, Jan Kiszka wrote:
> >> Calibrate the TSC and, where necessary, the APIC timer against the
> >> TMTIMER. We need our own implementation as neither the PIC nor the HPET
> >> are available, and the standard calibration routines try to make use of
> >> them.
> > 
> > Why is this needed at all?
> > 
> > The host the frequency already. So this can be done w/o pmtimer and extra
> > calibration routine.
> 
> The hypervisor does not have the frequencies. It will never use the APIC
> timer (it's owned by the guests), and it has no use case for the TSC so
> far. Only the root cell (the Linux that booted the system) has that
> data. Now we could
> 
> - trust the root cell to provide the right values and export them during
>   startup to the hypervisor and from there to the non-root cells.
> 
> - calculate the frequencies once and store them in the hyperivsor
>   config, just like other system-specific information, for re-export to
>   the cells.
> 
> But I don't think option 1 will be ok for all use cases. Maybe a
> combination of both, falling back to the root cell data if nothing is
> defined in the config. Let me think about this.

Another question is whether systems which can support jailhouse, have the
frequencies available via cpuid/msr and can avoid that calibration thing
completely.

Thanks,

tglx


Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-18 Thread Jan Kiszka
On 2017-11-17 23:49, Thomas Gleixner wrote:
> On Thu, 16 Nov 2017, Jan Kiszka wrote:
>> Calibrate the TSC and, where necessary, the APIC timer against the
>> TMTIMER. We need our own implementation as neither the PIC nor the HPET
>> are available, and the standard calibration routines try to make use of
>> them.
> 
> Why is this needed at all?
> 
> The host the frequency already. So this can be done w/o pmtimer and extra
> calibration routine.

The hypervisor does not have the frequencies. It will never use the APIC
timer (it's owned by the guests), and it has no use case for the TSC so
far. Only the root cell (the Linux that booted the system) has that
data. Now we could

- trust the root cell to provide the right values and export them during
  startup to the hypervisor and from there to the non-root cells.

- calculate the frequencies once and store them in the hyperivsor
  config, just like other system-specific information, for re-export to
  the cells.

But I don't think option 1 will be ok for all use cases. Maybe a
combination of both, falling back to the root cell data if nothing is
defined in the config. Let me think about this.

Jan


Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-18 Thread Jan Kiszka
On 2017-11-17 23:49, Thomas Gleixner wrote:
> On Thu, 16 Nov 2017, Jan Kiszka wrote:
>> Calibrate the TSC and, where necessary, the APIC timer against the
>> TMTIMER. We need our own implementation as neither the PIC nor the HPET
>> are available, and the standard calibration routines try to make use of
>> them.
> 
> Why is this needed at all?
> 
> The host the frequency already. So this can be done w/o pmtimer and extra
> calibration routine.

The hypervisor does not have the frequencies. It will never use the APIC
timer (it's owned by the guests), and it has no use case for the TSC so
far. Only the root cell (the Linux that booted the system) has that
data. Now we could

- trust the root cell to provide the right values and export them during
  startup to the hypervisor and from there to the non-root cells.

- calculate the frequencies once and store them in the hyperivsor
  config, just like other system-specific information, for re-export to
  the cells.

But I don't think option 1 will be ok for all use cases. Maybe a
combination of both, falling back to the root cell data if nothing is
defined in the config. Let me think about this.

Jan


Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-17 Thread Thomas Gleixner
On Thu, 16 Nov 2017, Jan Kiszka wrote:
> Calibrate the TSC and, where necessary, the APIC timer against the
> TMTIMER. We need our own implementation as neither the PIC nor the HPET
> are available, and the standard calibration routines try to make use of
> them.

Why is this needed at all?

The host the frequency already. So this can be done w/o pmtimer and extra
calibration routine.

Thanks,

tglx




Re: [PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-17 Thread Thomas Gleixner
On Thu, 16 Nov 2017, Jan Kiszka wrote:
> Calibrate the TSC and, where necessary, the APIC timer against the
> TMTIMER. We need our own implementation as neither the PIC nor the HPET
> are available, and the standard calibration routines try to make use of
> them.

Why is this needed at all?

The host the frequency already. So this can be done w/o pmtimer and extra
calibration routine.

Thanks,

tglx




[PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-15 Thread Jan Kiszka
From: Jan Kiszka 

Calibrate the TSC and, where necessary, the APIC timer against the
TMTIMER. We need our own implementation as neither the PIC nor the HPET
are available, and the standard calibration routines try to make use of
them.

Signed-off-by: Jan Kiszka 
---
 arch/x86/include/asm/tsc.h  |  3 ++
 arch/x86/kernel/jailhouse.c | 82 +
 arch/x86/kernel/tsc.c   | 14 
 3 files changed, 92 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/tsc.h b/arch/x86/include/asm/tsc.h
index cf5d53c3f9ea..be92e0c8ac17 100644
--- a/arch/x86/include/asm/tsc.h
+++ b/arch/x86/include/asm/tsc.h
@@ -71,4 +71,7 @@ extern void tsc_restore_sched_clock_state(void);
 
 unsigned long cpu_khz_from_msr(void);
 
+u64 tsc_read_refs(u64 *ref, int hpet);
+unsigned long tsc_calc_pmtimer_ref(u64 deltatsc, u64 pm1, u64 pm2);
+
 #endif /* _ASM_X86_TSC_H */
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index f7e99f7a8873..8e5b2f0c8a34 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -50,6 +50,83 @@ static uint32_t __init jailhouse_detect(void)
return jailhouse_cpuid_base();
 }
 
+#define MAX_RETRIES5
+#define SMI_TRESHOLD   5
+
+static unsigned long apic_timer_access(u64 *pmt, bool setup)
+{
+   unsigned long ret = 0;
+   unsigned int n;
+   u64 t1, t2;
+
+   for (n = 0; n < MAX_RETRIES; n++) {
+   t1 = get_cycles();
+   *pmt = acpi_pm_read_early();
+   if (setup)
+   apic_write(APIC_TMICT, 0x);
+   else
+   ret = apic_read(APIC_TMCCT);
+   t2 = get_cycles();
+
+   if ((t2 - t1) < SMI_TRESHOLD * 2)
+   return ret;
+   }
+
+   panic("Jailhouse: SMI disturbed APIC timer calibration");
+}
+
+static void jailhouse_timer_init(void)
+{
+   u64 divided_apic_freq;
+   unsigned long tmr;
+   u64 start, end;
+
+   if (boot_cpu_has(X86_FEATURE_TSC_DEADLINE_TIMER))
+   return;
+
+   apic_write(APIC_LVTT, APIC_LVT_MASKED);
+   apic_write(APIC_TDCR, APIC_TDR_DIV_16);
+
+   apic_timer_access(, true);
+   while ((acpi_pm_read_early() - start) < 10)
+   cpu_relax();
+   tmr = apic_timer_access(, false);
+
+   divided_apic_freq =
+   tsc_calc_pmtimer_ref((0xU - tmr) * 100, start, end);
+
+   lapic_timer_frequency = divided_apic_freq * 16;
+   apic_write(APIC_TMICT, 0);
+}
+
+static unsigned long jailhouse_calibrate_cpu(void)
+{
+   u64 tsc1, tsc2, pm1, pm2;
+   unsigned long flags;
+
+   local_irq_save(flags);
+
+   tsc1 = tsc_read_refs(, 0);
+   while ((get_cycles() - tsc1) < 5000)
+   cpu_relax();
+   tsc2 = tsc_read_refs(, 0);
+
+   local_irq_restore(flags);
+
+   /* Check, whether the sampling succeeded (SMI?) */
+   if (tsc1 == ULLONG_MAX || tsc2 == ULLONG_MAX) {
+   pr_err("Jailhouse: TSC calibration against PMTIMER failed\n");
+   return 0;
+   }
+
+   return tsc_calc_pmtimer_ref((tsc2 - tsc1) * 100, pm1, pm2);
+}
+
+static unsigned long jailhouse_calibrate_tsc(void)
+{
+   return 0;
+}
+
 static unsigned int x2apic_get_apic_id(unsigned long id)
 {
 return id;
@@ -61,6 +138,11 @@ static void __init jailhouse_init_platform(void)
struct jailhouse_setup_data *data;
unsigned int cpu;
 
+   x86_init.timers.timer_init  = jailhouse_timer_init;
+
+   x86_platform.calibrate_cpu = jailhouse_calibrate_cpu;
+   x86_platform.calibrate_tsc = jailhouse_calibrate_tsc;
+
data = early_memremap(pa_data, sizeof(*data));
 
if (data->header.type != SETUP_JAILHOUSE ||
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 8ea117f8142e..a61000cc4f21 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -286,7 +286,7 @@ __setup("tsc=", tsc_setup);
 /*
  * Read TSC and the reference counters. Take care of SMI disturbance
  */
-static u64 tsc_read_refs(u64 *p, int hpet)
+u64 tsc_read_refs(u64 *p, int hpet)
 {
u64 t1, t2;
int i;
@@ -307,7 +307,7 @@ static u64 tsc_read_refs(u64 *p, int hpet)
 /*
  * Calculate the TSC frequency from HPET reference
  */
-static unsigned long calc_hpet_ref(u64 deltatsc, u64 hpet1, u64 hpet2)
+static unsigned long tsc_calc_hpet_ref(u64 deltatsc, u64 hpet1, u64 hpet2)
 {
u64 tmp;
 
@@ -324,7 +324,7 @@ static unsigned long calc_hpet_ref(u64 deltatsc, u64 hpet1, 
u64 hpet2)
 /*
  * Calculate the TSC frequency from PMTimer reference
  */
-static unsigned long calc_pmtimer_ref(u64 deltatsc, u64 pm1, u64 pm2)
+unsigned long tsc_calc_pmtimer_ref(u64 deltatsc, u64 pm1, u64 pm2)
 {
u64 tmp;
 
@@ -728,9 +728,9 @@ unsigned long native_calibrate_cpu(void)
 
tsc2 = (tsc2 - tsc1) * 100LL;
  

[PATCH 05/10] x86: jailhouse: Set up timekeeping

2017-11-15 Thread Jan Kiszka
From: Jan Kiszka 

Calibrate the TSC and, where necessary, the APIC timer against the
TMTIMER. We need our own implementation as neither the PIC nor the HPET
are available, and the standard calibration routines try to make use of
them.

Signed-off-by: Jan Kiszka 
---
 arch/x86/include/asm/tsc.h  |  3 ++
 arch/x86/kernel/jailhouse.c | 82 +
 arch/x86/kernel/tsc.c   | 14 
 3 files changed, 92 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/tsc.h b/arch/x86/include/asm/tsc.h
index cf5d53c3f9ea..be92e0c8ac17 100644
--- a/arch/x86/include/asm/tsc.h
+++ b/arch/x86/include/asm/tsc.h
@@ -71,4 +71,7 @@ extern void tsc_restore_sched_clock_state(void);
 
 unsigned long cpu_khz_from_msr(void);
 
+u64 tsc_read_refs(u64 *ref, int hpet);
+unsigned long tsc_calc_pmtimer_ref(u64 deltatsc, u64 pm1, u64 pm2);
+
 #endif /* _ASM_X86_TSC_H */
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index f7e99f7a8873..8e5b2f0c8a34 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -50,6 +50,83 @@ static uint32_t __init jailhouse_detect(void)
return jailhouse_cpuid_base();
 }
 
+#define MAX_RETRIES5
+#define SMI_TRESHOLD   5
+
+static unsigned long apic_timer_access(u64 *pmt, bool setup)
+{
+   unsigned long ret = 0;
+   unsigned int n;
+   u64 t1, t2;
+
+   for (n = 0; n < MAX_RETRIES; n++) {
+   t1 = get_cycles();
+   *pmt = acpi_pm_read_early();
+   if (setup)
+   apic_write(APIC_TMICT, 0x);
+   else
+   ret = apic_read(APIC_TMCCT);
+   t2 = get_cycles();
+
+   if ((t2 - t1) < SMI_TRESHOLD * 2)
+   return ret;
+   }
+
+   panic("Jailhouse: SMI disturbed APIC timer calibration");
+}
+
+static void jailhouse_timer_init(void)
+{
+   u64 divided_apic_freq;
+   unsigned long tmr;
+   u64 start, end;
+
+   if (boot_cpu_has(X86_FEATURE_TSC_DEADLINE_TIMER))
+   return;
+
+   apic_write(APIC_LVTT, APIC_LVT_MASKED);
+   apic_write(APIC_TDCR, APIC_TDR_DIV_16);
+
+   apic_timer_access(, true);
+   while ((acpi_pm_read_early() - start) < 10)
+   cpu_relax();
+   tmr = apic_timer_access(, false);
+
+   divided_apic_freq =
+   tsc_calc_pmtimer_ref((0xU - tmr) * 100, start, end);
+
+   lapic_timer_frequency = divided_apic_freq * 16;
+   apic_write(APIC_TMICT, 0);
+}
+
+static unsigned long jailhouse_calibrate_cpu(void)
+{
+   u64 tsc1, tsc2, pm1, pm2;
+   unsigned long flags;
+
+   local_irq_save(flags);
+
+   tsc1 = tsc_read_refs(, 0);
+   while ((get_cycles() - tsc1) < 5000)
+   cpu_relax();
+   tsc2 = tsc_read_refs(, 0);
+
+   local_irq_restore(flags);
+
+   /* Check, whether the sampling succeeded (SMI?) */
+   if (tsc1 == ULLONG_MAX || tsc2 == ULLONG_MAX) {
+   pr_err("Jailhouse: TSC calibration against PMTIMER failed\n");
+   return 0;
+   }
+
+   return tsc_calc_pmtimer_ref((tsc2 - tsc1) * 100, pm1, pm2);
+}
+
+static unsigned long jailhouse_calibrate_tsc(void)
+{
+   return 0;
+}
+
 static unsigned int x2apic_get_apic_id(unsigned long id)
 {
 return id;
@@ -61,6 +138,11 @@ static void __init jailhouse_init_platform(void)
struct jailhouse_setup_data *data;
unsigned int cpu;
 
+   x86_init.timers.timer_init  = jailhouse_timer_init;
+
+   x86_platform.calibrate_cpu = jailhouse_calibrate_cpu;
+   x86_platform.calibrate_tsc = jailhouse_calibrate_tsc;
+
data = early_memremap(pa_data, sizeof(*data));
 
if (data->header.type != SETUP_JAILHOUSE ||
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 8ea117f8142e..a61000cc4f21 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -286,7 +286,7 @@ __setup("tsc=", tsc_setup);
 /*
  * Read TSC and the reference counters. Take care of SMI disturbance
  */
-static u64 tsc_read_refs(u64 *p, int hpet)
+u64 tsc_read_refs(u64 *p, int hpet)
 {
u64 t1, t2;
int i;
@@ -307,7 +307,7 @@ static u64 tsc_read_refs(u64 *p, int hpet)
 /*
  * Calculate the TSC frequency from HPET reference
  */
-static unsigned long calc_hpet_ref(u64 deltatsc, u64 hpet1, u64 hpet2)
+static unsigned long tsc_calc_hpet_ref(u64 deltatsc, u64 hpet1, u64 hpet2)
 {
u64 tmp;
 
@@ -324,7 +324,7 @@ static unsigned long calc_hpet_ref(u64 deltatsc, u64 hpet1, 
u64 hpet2)
 /*
  * Calculate the TSC frequency from PMTimer reference
  */
-static unsigned long calc_pmtimer_ref(u64 deltatsc, u64 pm1, u64 pm2)
+unsigned long tsc_calc_pmtimer_ref(u64 deltatsc, u64 pm1, u64 pm2)
 {
u64 tmp;
 
@@ -728,9 +728,9 @@ unsigned long native_calibrate_cpu(void)
 
tsc2 = (tsc2 - tsc1) * 100LL;
if (hpet)
-   tsc2 =