linux-kernel - Re: Fix lapic time counter read for periodic mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121112213237.GA31377@amt.cnet>
Date:	Mon, 12 Nov 2012 19:32:37 -0200
From:	Marcelo Tosatti <mtosatti@...hat.com>
To:	Christian Ehrhardt <lk@...e.de>
Cc:	Avi Kivity <avi@...hat.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Fix lapic time counter read for periodic mode

On Sun, Nov 11, 2012 at 01:25:28PM +0100, Christian Ehrhardt wrote:
> 
> Hi,
> 
> there is a bug in the emulation of the lapic time counter. In particular
> what we are seeing is that the time counter of a periodic lapic timer
> in the guest reads as zero 99% of the time. The patch below fixes that.
> 
> The emulation of the lapic timer is done with the help of a hires
> timer that expires with the same frequency as the lapic counter.
> New expiration times for a periodic timer are calculated incrementally
> based on the last scheduled expiration time. This ensures long term
> accuracy of the emulated timer close to that of the underlying clock.
> 
> The actual value of the lapic time counter is calculated from the
> real time difference between current time and scheduled expiration time
> of the hires timer. If this difference is negative, the hires timer
> expired. For oneshot mode this is correctly translated into a zero value
> for the time counter. However, in periodic mode we must use the negative
> difference unmodified.
> 
>      regards   Christian
> 
> Fix lapic time counter read for periodic mode.

In periodic mode the hrtimer is rearmed once expired, see
apic_timer_fn. So _get_remaining should return proper value
even if the guest is not able to process timer interrupts. 

Can you describe your specific scenario in more detail?

> Signed-off-by: Christian Ehrhardt <lk@...e.de>
> 
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 43e9fad..eff902d 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -810,8 +810,13 @@ static u32 apic_get_tmcct(struct kvm_lapic *apic)
>  	if (kvm_apic_get_reg(apic, APIC_TMICT) == 0)
>  		return 0;
>  
> +	/*
> +	 * hrtimer_get_remaining returns the signed difference between
> +	 * timer expiration time and current time. Keep negative return
> +	 * value iff the the timer is periodic.
> +	 */
>  	remaining = hrtimer_get_remaining(&apic->lapic_timer.timer);
> -	if (ktime_to_ns(remaining) < 0)
> +	if (ktime_to_ns(remaining) < 0 && !apic_lvtt_period(apic))
>  		remaining = ktime_set(0, 0);
>  
>  	ns = mod_64(ktime_to_ns(remaining), apic->lapic_timer.period);
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/