From patchwork Thu Jan 31 18:37:06 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Jerome Glisse X-Patchwork-Id: 10791169 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id F10EC139A for ; Thu, 31 Jan 2019 18:37:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E8219310F5 for ; Thu, 31 Jan 2019 18:37:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DC85C31111; Thu, 31 Jan 2019 18:37:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 83966310F5 for ; Thu, 31 Jan 2019 18:37:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727976AbfAaShY (ORCPT ); Thu, 31 Jan 2019 13:37:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44030 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727947AbfAaShU (ORCPT ); Thu, 31 Jan 2019 13:37:20 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9F27F3D09; Thu, 31 Jan 2019 18:37:20 +0000 (UTC) Received: from localhost.localdomain.com (unknown [10.20.6.236]) by smtp.corp.redhat.com (Postfix) with ESMTP id A757217F7D; Thu, 31 Jan 2019 18:37:19 +0000 (UTC) From: jglisse@redhat.com To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, =?utf-8?b?SsOpcsO0bWUgR2xpc3Nl?= , Andrea Arcangeli , Peter Xu , Andrew Morton , Paolo Bonzini , =?utf-8?b?UmFkaW0gS3LEjW3DocWZ?= , kvm@vger.kernel.org Subject: [RFC PATCH 4/4] kvm/mmu_notifier: re-enable the change_pte() optimization. Date: Thu, 31 Jan 2019 13:37:06 -0500 Message-Id: <20190131183706.20980-5-jglisse@redhat.com> In-Reply-To: <20190131183706.20980-1-jglisse@redhat.com> References: <20190131183706.20980-1-jglisse@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 31 Jan 2019 18:37:20 +0000 (UTC) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Jérôme Glisse Since changes to mmu notifier the change_pte() optimization was lost for kvm. This re-enable it, when ever a pte is going from read and write to read only with same pfn, or from read only to read and write with different pfn. It is safe to update the secondary MMUs, because the primary MMU pte invalidate must have already happened with a ptep_clear_flush() before set_pte_at_notify() is invoked (and thus before change_pte() callback). Signed-off-by: Jérôme Glisse Cc: Andrea Arcangeli Cc: Peter Xu Cc: Andrew Morton Cc: Paolo Bonzini Cc: Radim Krčmář Cc: kvm@vger.kernel.org --- virt/kvm/kvm_main.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 5ecea812cb6a..fec155c2d7b8 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -369,6 +369,14 @@ static int kvm_mmu_notifier_invalidate_range_start(struct mmu_notifier *mn, int need_tlb_flush = 0, idx; int ret; + /* + * Nothing to do when MMU_NOTIFIER_USE_CHANGE_PTE is set as it means + * that change_pte() will be call and it is a situation in which we + * allow to only rely on change_pte(). + */ + if (range->event & MMU_NOTIFIER_USE_CHANGE_PTE) + return 0; + idx = srcu_read_lock(&kvm->srcu); spin_lock(&kvm->mmu_lock); /* @@ -398,6 +406,14 @@ static void kvm_mmu_notifier_invalidate_range_end(struct mmu_notifier *mn, { struct kvm *kvm = mmu_notifier_to_kvm(mn); + /* + * Nothing to do when MMU_NOTIFIER_USE_CHANGE_PTE is set as it means + * that change_pte() will be call and it is a situation in which we + * allow to only rely on change_pte(). + */ + if (range->event & MMU_NOTIFIER_USE_CHANGE_PTE) + return; + spin_lock(&kvm->mmu_lock); /* * This sequence increase will notify the kvm page fault that