From mboxrd@z Thu Jan  1 00:00:00 1970
From: Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>
Subject: Re: [PATCH v6 3/3] KVM: LAPIC: Apply change to TDCR right away to
 the timer
Date: Fri, 6 Oct 2017 16:14:53 +0200
Message-ID: <20171006141453.GD16466@flask>
References: <1507254866-5020-1-git-send-email-wanpeng.li@hotmail.com>
 <1507254866-5020-4-git-send-email-wanpeng.li@hotmail.com>
 <20171006131453.GB16466@flask>
 <CANRm+CxOuuA6z-5TMkdvMoDOdbW1Bv16BAC40maWcjEs32jJGA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        kvm <kvm@vger.kernel.org>, Paolo Bonzini <pbonzini@redhat.com>,
        Wanpeng Li <wanpeng.li@hotmail.com>
To: Wanpeng Li <kernellwp@gmail.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <CANRm+CxOuuA6z-5TMkdvMoDOdbW1Bv16BAC40maWcjEs32jJGA@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

2017-10-06 21:59+0800, Wanpeng Li:
> 2017-10-06 21:14 GMT+08:00 Radim Krčmář <rkrcmar@redhat.com>:
> > 2017-10-05 18:54-0700, Wanpeng Li:
> >> From: Wanpeng Li <wanpeng.li@hotmail.com>
> >>
> >> The description in the Intel SDM of how the divide configuration
> >> register is used: "The APIC timer frequency will be the processor's bus
> >> clock or core crystal clock frequency divided by the value specified in
> >> the divide configuration register."
> >>
> >> Observation of baremetal shown that when the TDCR is change, the TMCCT
> >> does not change or make a big jump in value, but the rate at which it
> >> count down change.
> >>
> >> The patch update the emulation to APIC timer to so that a change to the
> >> divide configuration would be reflected in the value of the counter and
> >> when the next interrupt is triggered.
> >>
> >> Cc: Paolo Bonzini <pbonzini@redhat.com>
> >> Cc: Radim Krčmář <rkrcmar@redhat.com>
> >> Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
> >> ---
> >> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> >> @@ -1458,6 +1458,36 @@ static void start_sw_period(struct kvm_lapic *apic)
> >> +static bool update_target_expiration(struct kvm_lapic *apic, uint32_t old_divisor)
> >> +{
> >> +     ktime_t now, remaining;
> >> +     u64 tscl = rdtsc(), delta;
> >> +
> >> +     now = ktime_get();
> >> +     remaining = ktime_sub(apic->lapic_timer.target_expiration, now);
> >> +     if (ktime_to_ns(remaining) < 0)
> >> +             remaining = 0;
> >> +     delta = mod_64(ktime_to_ns(remaining), apic->lapic_timer.period);
> >
> > Hm, can this happen?
> 
> Yeah, when the hrtimer has already expired. I can catch it during testing.

I thought that "if (ktime_to_ns(remaining) < 0)" is there to catch that,
isn't that a bug elsewhere?