All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH RFC] x86/lapic: remove the PIT usage to calibrate the lapic timer
@ 2018-09-19 16:25 Roger Pau Monne
  2018-09-19 16:47 ` Vitaly Kuznetsov
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Roger Pau Monne @ 2018-09-19 16:25 UTC (permalink / raw)
  To: xen-devel; +Cc: Andrew Cooper, Wei Liu, Jan Beulich, Roger Pau Monne

And instead use NOW which is based on the TSC. This was already used
when running in shim mode, since there's likely no PIT in that
environment.

Remove printing the CPU frequency, since it's already printed earlier
at boot, and getting the CPU frequency against the TSC without any
external reference timer is pointless.

The motivation behind this change is to allow Xen to boot on HyperV
gen2 instances, which lack a PIT.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
I'm not sure about the reason behind the usage of the PIT instead of
the TSC, maybe this was done because the TSC wasn't available until
the Pentium? Xen certainly doesn't care about such hardware anymore,
and the TSC is already used unconditionally in Xen.

Linux seems to prefer to calibrate the lapic timer against the PM
timer and has already dropped PIT usage for that.

My early tests on a single box show no differences between the TSC or
the PIT for lapic timer calibration, but that's a single box.

The RFC is because I'm not sure I understand the motivation for using
the PIT in the first place, so I might be missing something relevant
that could make this patch moot.
---
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
 xen/arch/x86/apic.c | 67 ++-------------------------------------------
 1 file changed, 2 insertions(+), 65 deletions(-)

diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 88ada9d0ec..21dbeb2298 100644
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1010,46 +1010,6 @@ __next:
 /* used for system time scaling */
 static u32 __read_mostly bus_scale; /* scaling factor: ns -> bus cycles */
 
-/*
- * The timer chip is already set up at HZ interrupts per second here,
- * but we do not accept timer interrupts yet. We only allow the BP
- * to calibrate.
- */
-static unsigned int __init get_8254_timer_count(void)
-{
-    /*extern spinlock_t i8253_lock;*/
-    /*unsigned long flags;*/
-
-    unsigned int count;
-
-    /*spin_lock_irqsave(&i8253_lock, flags);*/
-
-    outb_p(0x00, PIT_MODE);
-    count = inb_p(PIT_CH0);
-    count |= inb_p(PIT_CH0) << 8;
-
-    /*spin_unlock_irqrestore(&i8253_lock, flags);*/
-
-    return count;
-}
-
-/* next tick in 8254 can be caught by catching timer wraparound */
-static void __init wait_8254_wraparound(void)
-{
-    unsigned int curr_count, prev_count;
-    
-    curr_count = get_8254_timer_count();
-    do {
-        prev_count = curr_count;
-        curr_count = get_8254_timer_count();
-
-        /* workaround for broken Mercury/Neptune */
-        if (prev_count >= curr_count + 0x100)
-            curr_count = get_8254_timer_count();
-        
-    } while (prev_count >= curr_count);
-}
-
 /*
  * This function sets up the local APIC timer, with a timeout of
  * 'clocks' APIC bus clock. During calibration we actually call
@@ -1092,7 +1052,7 @@ static void setup_APIC_timer(void)
     local_irq_restore(flags);
 }
 
-static void wait_tick_pvh(void)
+static void wait_tick(void)
 {
     u64 lapse_ns = 1000000000ULL / HZ;
     s_time_t start, curr_time;
@@ -1121,7 +1081,6 @@ static void wait_tick_pvh(void)
 
 static int __init calibrate_APIC_clock(void)
 {
-    unsigned long long t1, t2;
     long tt1, tt2;
     long result;
     int i;
@@ -1138,33 +1097,15 @@ static int __init calibrate_APIC_clock(void)
      */
     __setup_APIC_LVTT(1000000000);
 
-    if ( !xen_guest )
-        /*
-         * The timer chip counts down to zero. Let's wait
-         * for a wraparound to start exact measurement:
-         * (the current tick might have been already half done)
-         */
-        wait_8254_wraparound();
-    else
-        wait_tick_pvh();
-
-    /*
-     * We wrapped around just now. Let's start:
-     */
-    t1 = rdtsc_ordered();
     tt1 = apic_read(APIC_TMCCT);
 
     /*
      * Let's wait LOOPS ticks:
      */
     for (i = 0; i < LOOPS; i++)
-        if ( !xen_guest )
-            wait_8254_wraparound();
-        else
-            wait_tick_pvh();
+        wait_tick();
 
     tt2 = apic_read(APIC_TMCCT);
-    t2 = rdtsc_ordered();
 
     /*
      * The APIC bus clock counter is 32 bits only, it
@@ -1176,10 +1117,6 @@ static int __init calibrate_APIC_clock(void)
 
     result = (tt1-tt2)*APIC_DIVISOR/LOOPS;
 
-    apic_printk(APIC_VERBOSE, "..... CPU clock speed is %ld.%04ld MHz.\n",
-                ((long)(t2 - t1) / LOOPS) / (1000000 / HZ),
-                ((long)(t2 - t1) / LOOPS) % (1000000 / HZ));
-
     apic_printk(APIC_VERBOSE, "..... host bus clock speed is %ld.%04ld MHz.\n",
                 result / (1000000 / HZ), result % (1000000 / HZ));
 
-- 
2.19.0


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

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] x86/lapic: remove the PIT usage to calibrate the lapic timer
  2018-09-19 16:25 [PATCH RFC] x86/lapic: remove the PIT usage to calibrate the lapic timer Roger Pau Monne
@ 2018-09-19 16:47 ` Vitaly Kuznetsov
  2018-09-19 16:48 ` Wei Liu
  2018-09-20  8:18 ` Jan Beulich
  2 siblings, 0 replies; 4+ messages in thread
From: Vitaly Kuznetsov @ 2018-09-19 16:47 UTC (permalink / raw)
  To: Roger Pau Monne; +Cc: xen-devel, Wei Liu, Jan Beulich, Andrew Cooper

Roger Pau Monne <roger.pau@citrix.com> writes:

> And instead use NOW which is based on the TSC. This was already used
> when running in shim mode, since there's likely no PIT in that
> environment.
>
> Remove printing the CPU frequency, since it's already printed earlier
> at boot, and getting the CPU frequency against the TSC without any
> external reference timer is pointless.
>
> The motivation behind this change is to allow Xen to boot on HyperV
> gen2 instances, which lack a PIT.

When on Hyper-V, LAPIC frequency can easily be queried from
HV_X64_MSR_APIC_FREQUENCY (and that's what Linux does nowdays). This, of
course, only if Hyper-V provides the interface but it always does.

-- 
  Vitaly

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] x86/lapic: remove the PIT usage to calibrate the lapic timer
  2018-09-19 16:25 [PATCH RFC] x86/lapic: remove the PIT usage to calibrate the lapic timer Roger Pau Monne
  2018-09-19 16:47 ` Vitaly Kuznetsov
@ 2018-09-19 16:48 ` Wei Liu
  2018-09-20  8:18 ` Jan Beulich
  2 siblings, 0 replies; 4+ messages in thread
From: Wei Liu @ 2018-09-19 16:48 UTC (permalink / raw)
  To: Roger Pau Monne; +Cc: xen-devel, Wei Liu, Jan Beulich, Andrew Cooper

On Wed, Sep 19, 2018 at 06:25:54PM +0200, Roger Pau Monne wrote:
> And instead use NOW which is based on the TSC. This was already used
> when running in shim mode, since there's likely no PIT in that
> environment.
> 
> Remove printing the CPU frequency, since it's already printed earlier
> at boot, and getting the CPU frequency against the TSC without any
> external reference timer is pointless.
> 
> The motivation behind this change is to allow Xen to boot on HyperV
> gen2 instances, which lack a PIT.

lacks

> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> I'm not sure about the reason behind the usage of the PIT instead of
> the TSC, maybe this was done because the TSC wasn't available until
> the Pentium? Xen certainly doesn't care about such hardware anymore,
> and the TSC is already used unconditionally in Xen.
> 
> Linux seems to prefer to calibrate the lapic timer against the PM
> timer and has already dropped PIT usage for that.
> 
> My early tests on a single box show no differences between the TSC or
> the PIT for lapic timer calibration, but that's a single box.
> 
> The RFC is because I'm not sure I understand the motivation for using
> the PIT in the first place, so I might be missing something relevant
> that could make this patch moot.

I wondered the same.

Wei.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RFC] x86/lapic: remove the PIT usage to calibrate the lapic timer
  2018-09-19 16:25 [PATCH RFC] x86/lapic: remove the PIT usage to calibrate the lapic timer Roger Pau Monne
  2018-09-19 16:47 ` Vitaly Kuznetsov
  2018-09-19 16:48 ` Wei Liu
@ 2018-09-20  8:18 ` Jan Beulich
  2 siblings, 0 replies; 4+ messages in thread
From: Jan Beulich @ 2018-09-20  8:18 UTC (permalink / raw)
  To: Roger Pau Monne; +Cc: Andrew Cooper, Wei Liu, xen-devel

>>> On 19.09.18 at 18:25, <roger.pau@citrix.com> wrote:
> And instead use NOW which is based on the TSC. This was already used
> when running in shim mode, since there's likely no PIT in that
> environment.
> 
> Remove printing the CPU frequency, since it's already printed earlier
> at boot, and getting the CPU frequency against the TSC without any
> external reference timer is pointless.
> 
> The motivation behind this change is to allow Xen to boot on HyperV
> gen2 instances, which lack a PIT.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> ---
> I'm not sure about the reason behind the usage of the PIT instead of
> the TSC, maybe this was done because the TSC wasn't available until
> the Pentium? Xen certainly doesn't care about such hardware anymore,
> and the TSC is already used unconditionally in Xen.

How good are the chances that on at least some hardware LAPIC
and TSC frequencies derive from the same oscillator? If they do,
you'd now basically calibrate a clock against itself, ...

> Linux seems to prefer to calibrate the lapic timer against the PM
> timer and has already dropped PIT usage for that.

... while this is almost certainly using a completely different timer,
with the possible (hypothetical?) exception of SoC-s.

Also, if we were to change the default against which clock to
calibrate, I think we'd at least want to have a command line option
controllable fallback to the current mode, just in case of unforeseen
problems. This could be dropped a couple of releases later, if we
really want to get rid of that code.

> @@ -1176,10 +1117,6 @@ static int __init calibrate_APIC_clock(void)
>  
>      result = (tt1-tt2)*APIC_DIVISOR/LOOPS;
>  
> -    apic_printk(APIC_VERBOSE, "..... CPU clock speed is %ld.%04ld MHz.\n",
> -                ((long)(t2 - t1) / LOOPS) / (1000000 / HZ),
> -                ((long)(t2 - t1) / LOOPS) % (1000000 / HZ));
> -

I think I dislike this removal, despite the apparent redundancy, and
in particular as part of an unrelated patch. It sitting next to

>      apic_printk(APIC_VERBOSE, "..... host bus clock speed is %ld.%04ld MHz.\n",
>                  result / (1000000 / HZ), result % (1000000 / HZ));

is quite helpful imo, and APIC_VERBOSE mode is off by default
anyway.

Jan


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2018-09-20  8:18 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-19 16:25 [PATCH RFC] x86/lapic: remove the PIT usage to calibrate the lapic timer Roger Pau Monne
2018-09-19 16:47 ` Vitaly Kuznetsov
2018-09-19 16:48 ` Wei Liu
2018-09-20  8:18 ` Jan Beulich

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.