From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH 4/4] KVM: x86: remove notifiers from PIT discard policy Date: Thu, 4 Feb 2016 14:15:59 +0100 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-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Yuki Shibuya To: Paolo Bonzini Return-path: Content-Disposition: inline In-Reply-To: <56B23009.1020109@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 2016-02-03 17:51+0100, Paolo Bonzini: > On 03/02/2016 17:23, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> Discard policy doesn't rely on information from notifiers, so we don= 't >> need to register notifiers unconditionally. >>=20 >> 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 th= e 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. >=20 > Can you however add a patch that says what fields of kvm_kpit_state a= re > protected by which locks? Ok. (I'll be careful to not rewrite the whole PIT while at it. :]) > Then this patch will just add >=20 > /* Protected by kvm_kpit_state lock. */ >=20 > above the reinject field. There was no need to lock reinject in the past and v2 will hopefully achieve it again. > Otherwise >=20 > Reviewed-by: Paolo Bonzini Thanks. (Might not be applicable to v2, though; sorry.)