From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965941AbcBDNQL (ORCPT ); Thu, 4 Feb 2016 08:16:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36955 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965351AbcBDNQJ (ORCPT ); Thu, 4 Feb 2016 08:16:09 -0500 Date: Thu, 4 Feb 2016 14:15:59 +0100 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Yuki Shibuya Subject: Re: [PATCH 4/4] KVM: x86: remove notifiers from PIT discard policy Message-ID: <20160204131558.GA9295@potion.brq.redhat.com> References: <1454516585-28491-1-git-send-email-rkrcmar@redhat.com> <1454516585-28491-5-git-send-email-rkrcmar@redhat.com> <56B23009.1020109@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56B23009.1020109@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2016-02-03 17:51+0100, Paolo Bonzini: > On 03/02/2016 17:23, Radim Krčmář wrote: >> Discard policy doesn't rely on information from notifiers, so we don't >> need to register notifiers unconditionally. >> >> Use of ps->lock doesn't make sense, but isn't any worse than before. Oops, it is worse than before ... toggling KVM_REINJECT_CONTROL when the guest is running and reading reinject without locking is now far more complex. This patch should have also ignored KVM_REINJECT_CONTROL when PIT has been started. > Oh, it's perfectly okay. Too fine-grained locks are bad, and lock > contention on ps->lock is a non-issue. > > Can you however add a patch that says what fields of kvm_kpit_state are > protected by which locks? Ok. (I'll be careful to not rewrite the whole PIT while at it. :]) > Then this patch will just add > > /* Protected by kvm_kpit_state lock. */ > > above the reinject field. There was no need to lock reinject in the past and v2 will hopefully achieve it again. > Otherwise > > Reviewed-by: Paolo Bonzini Thanks. (Might not be applicable to v2, though; sorry.)