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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161227080644.GA5370@yu-desktop-1.sh.intel.com>
Date:   Tue, 27 Dec 2016 16:06:44 +0800
From:   Chen Yu <yu.c.chen@...el.com>
To:     Marcelo Tosatti <mtosatti@...hat.com>
Cc:     kvm@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krcmar <rkrcmar@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Wanpeng Li <wanpeng.li@...mail.com>
Subject: Re: [PATCH][RFC] VM: x86: Return ealier if clocksource has not
 changed

Hi Marcelo,
On Mon, Dec 26, 2016 at 05:44:25PM -0200, Marcelo Tosatti wrote:
> On Fri, Dec 23, 2016 at 04:41:53PM +0800, Chen Yu wrote:
> > Currently the notifier of pvclock_gtod_notify() get invoked
> > frequently due to the periodic update_wall_time(). This might
> > slow down the system a little bit as there might be redundant
> > execution code path and unnecessary lock contention
> > in update_pvclock_gtod(), which was found when I was doing
> > suspend/resume speed testings. As pvclock_gtod_notify()
> > should be invoked only when clocksource has changed, according to
> > Commit 16e8d74d2da9 ("KVM: x86: notifier for clocksource changes")
> > , either we can add a new notifier for clocksource switch,
> > or we can simply bypass the following code in pvclock_gtod_notify()
> > earlier if there is no clocksource switch.
> > 
> > Cc: Paolo Bonzini <pbonzini@...hat.com>
> > Cc: "Radim Krcmar" <rkrcmar@...hat.com>
> > Cc: Marcelo Tosatti <mtosatti@...hat.com>
> > Cc: Thomas Gleixner <tglx@...utronix.de>
> > Cc: Ingo Molnar <mingo@...hat.com>
> > Cc: "H. Peter Anvin" <hpa@...or.com>
> > Cc: Wanpeng Li <wanpeng.li@...mail.com>
> > Signed-off-by: Chen Yu <yu.c.chen@...el.com>
> > ---
> >  arch/x86/kvm/x86.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index 445c51b..54aa32d 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -5961,13 +5961,14 @@ static int pvclock_gtod_notify(struct notifier_block *nb, unsigned long unused,
> >  	struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
> >  	struct timekeeper *tk = priv;
> >  
> > +	if (likely(gtod->clock.vclock_mode == VCLOCK_TSC))
> > +		return 0;
> 
> I think this is only safe if any of the values in "struct
> pvclock_gtod_data" are unchanged. Otherwise the local (KVM) copy is 
> kept incorrect.
I missread the code previously and I thought only under the condition
the clocksource has been switched to another one will the KVM copy
be touched. Apparently it is not the case because the copy should
be updated on-time during normal tick, right?
thanks for your reply,
Yu
> 
> >  	update_pvclock_gtod(tk);
> >  
> >  	/* disable master clock if host does not trust, or does not
> >  	 * use, TSC clocksource
> >  	 */
> > -	if (gtod->clock.vclock_mode != VCLOCK_TSC &&
> > -	    atomic_read(&kvm_guest_has_master_clock) != 0)
> > +	if (atomic_read(&kvm_guest_has_master_clock) != 0)
> >  		queue_work(system_long_wq, &pvclock_gtod_work);
> >  
> >  	return 0;
> > -- 
> > 2.7.4

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ