From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932337AbcEKPUK (ORCPT <rfc822;w@1wt.eu>);
	Wed, 11 May 2016 11:20:10 -0400
Received: from mail-pa0-f68.google.com ([209.85.220.68]:34083 "EHLO
	mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751777AbcEKPUH (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 11 May 2016 11:20:07 -0400
Date: Wed, 11 May 2016 23:19:57 +0800
From: Minfei Huang <mnghuan@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>, Borislav Petkov <bp@suse.de>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        X86 ML <x86@kernel.org>, Marcelo Tosatti <mtosatti@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] Cleanup __pvclock_read_cycles to remove useless variables
Message-ID: <20160511151957.GA12280@huangminfeis-MacBook-Pro.local>
References: <1461567194-2007-1-git-send-email-mnghuan@gmail.com>
 <20160430132420.GA4084@pd.tnic>
 <CALCETrVy6=N+6oRSdSYgBikpfJGDTfCfV13a_HcWVfE-zdm8hg@mail.gmail.com>
 <20160430191734.GB4084@pd.tnic>
 <CALCETrVwn_bqeuuv7UbZzr8T2M+krjaDNgrqWd3vX0gujPm5sA@mail.gmail.com>
 <573340A5.1090209@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <573340A5.1090209@redhat.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 05/11/16 at 04:24P, Paolo Bonzini wrote:
> 
> 
> On 30/04/2016 23:57, Andy Lutomirski wrote:
> >> > Should we kill __pvclock_read_cycles in favor of vread_pvclock? It looks
> >> > doable at a quick scan...
> >> >
> > The in-kernel version might have to be a bit different because it
> > needs to handle the !stable case.  If !stable, it should just use the
> > current CPU's copy which means that, realistically, it should just
> > get_cpu and use the local copy unconditionally.  Other than that, it
> > could look a lot like the vread_pvclock variant.
> > 
> > But I agree, the current thing is incomprehensible.
> 
> It also lacks smp_rmb()s.  One is more or less implicit in rdtsc, but
> you need one to separate __pvclock_read_cycles's reads of src->foo from
> pvclock_read_flags's read of src->version.
> 
> Minfei, would you like to take a look?

Sure. I will take a look about this issue.

Thanks
Minfei

> 
> Paolo