From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758065AbbFQHrd (ORCPT ); Wed, 17 Jun 2015 03:47:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35645 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758038AbbFQHrQ (ORCPT ); Wed, 17 Jun 2015 03:47:16 -0400 Message-ID: <558125FC.7010007@redhat.com> Date: Wed, 17 Jun 2015 09:47:08 +0200 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Andy Lutomirski , x86@kernel.org CC: Borislav Petkov , Peter Zijlstra , John Stultz , linux-kernel@vger.kernel.org, Len Brown , Huang Rui , Denys Vlasenko , kvm@vger.kernel.org, Ralf Baechle , Radim Krcmar , Marcelo Tosatti Subject: Re: [PATCH v3 17/18] x86/kvm/tsc: Drop extra barrier and use rdtsc_ordered in kvmclock References: <678981cc4761fb38a793c217c9cac42503cf3719.1434501121.git.luto@kernel.org> In-Reply-To: <678981cc4761fb38a793c217c9cac42503cf3719.1434501121.git.luto@kernel.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/06/2015 02:36, Andy Lutomirski wrote: > __pvclock_read_cycles had an unnecessary barrier. Get rid of that > barrier and clean up the code by just using rdtsc_ordered(). > > Cc: Paolo Bonzini > Cc: Radim Krcmar > Cc: Marcelo Tosatti > Cc: kvm@vger.kernel.org > Signed-off-by: Andy Lutomirski > --- > > I'm hoping to get an ack for this to go in through -tip. (Arguably > I'm the maintainer of this code given how it's used, but I should > still ask for an ack.) > > arch/x86/include/asm/pvclock.h | 21 ++++++++++++--------- > 1 file changed, 12 insertions(+), 9 deletions(-) Can you send a URL to the rest of the series? I've never even seen v1 or v2 so I have no idea of what this is about. > diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h > index 6084bce345fc..cf2329ca4812 100644 > --- a/arch/x86/include/asm/pvclock.h > +++ b/arch/x86/include/asm/pvclock.h > @@ -62,7 +62,18 @@ static inline u64 pvclock_scale_delta(u64 delta, u32 mul_frac, int shift) > static __always_inline > u64 pvclock_get_nsec_offset(const struct pvclock_vcpu_time_info *src) > { > - u64 delta = rdtsc() - src->tsc_timestamp; > + /* > + * Note: emulated platforms which do not advertise SSE2 support > + * break rdtsc_ordered, resulting in kvmclock not using the > + * necessary RDTSC barriers. Without barriers, it is possible > + * that RDTSC instruction is executed before prior loads, > + * resulting in violation of monotonicity. > + * > + * On an SMP guest without SSE2, it's unclear how anything is > + * supposed to work correctly, though -- memory fences > + * (e.g. smp_mb) are important for more than just timing. > + */ On an SMP guest without SSE2, memory fences are obtained with e.g. "lock addb $0, (%esp)". > + u64 delta = rdtsc_ordered() - src->tsc_timestamp; > return pvclock_scale_delta(delta, src->tsc_to_system_mul, > src->tsc_shift); > } > @@ -76,17 +87,9 @@ unsigned __pvclock_read_cycles(const struct pvclock_vcpu_time_info *src, > u8 ret_flags; > > version = src->version; > - /* Note: emulated platforms which do not advertise SSE2 support > - * result in kvmclock not using the necessary RDTSC barriers. > - * Without barriers, it is possible that RDTSC instruction reads from > - * the time stamp counter outside rdtsc_barrier protected section > - * below, resulting in violation of monotonicity. > - */ > - rdtsc_barrier(); > offset = pvclock_get_nsec_offset(src); > ret = src->system_time + offset; > ret_flags = src->flags; > - rdtsc_barrier(); > > *cycles = ret; > *flags = ret_flags; >