From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3A88C54EE9 for ; Sun, 18 Sep 2022 13:11:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229514AbiIRNLL (ORCPT ); Sun, 18 Sep 2022 09:11:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59726 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229479AbiIRNLI (ORCPT ); Sun, 18 Sep 2022 09:11:08 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 517781F2CD; Sun, 18 Sep 2022 06:11:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1663506663; x=1695042663; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=gxjMkXkrtlGL6/dieHu87TQsocsXooZYX/tz1fHL+6c=; b=aCg5QMyrKTVQGKD7uYgMgSKoficsaecZhfvY52fqR0UotvVot4cm+6da 0kvA2gJArHOhpcz8skQi1Spj9e0Z+6dL8kagQIGvIfM225TV2ULh4k77t npAx3cySR5Gp+kfnookykoUyM7YKPeDvyFs7bNVeLE8/YNBBeJSE2A2bd JQ/7AxPrGwWzinYEBUZTP1OVj4KrX+SX8DgUvPeecdc6mtse5Bw6cjebC ijO/97FFbA5Sg7vepottiV0UV1k9Dk5seJq49JI9YZOPpj+TwXjbwmEMD GuIyaA1oOqANEiZT8dhH+vpucDUjHVE9RnEbzdc6cebUqoEdtZIxTxcab w==; X-IronPort-AV: E=McAfee;i="6500,9779,10474"; a="278963149" X-IronPort-AV: E=Sophos;i="5.93,325,1654585200"; d="scan'208";a="278963149" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Sep 2022 06:11:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,325,1654585200"; d="scan'208";a="707278242" Received: from sqa-gate.sh.intel.com (HELO robert-ivt.tsp.org) ([10.239.48.212]) by FMSMGA003.fm.intel.com with ESMTP; 18 Sep 2022 06:11:00 -0700 Message-ID: Subject: Re: [PATCH v2 1/6] KVM: x86/mmu: Fix wrong gfn range of tlb flushing in validate_direct_spte() From: Robert Hoo To: Hou Wenlong , kvm@vger.kernel.org Cc: David Matlack , Sean Christopherson , Paolo Bonzini , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Lan Tianyu , linux-kernel@vger.kernel.org Date: Sun, 18 Sep 2022 21:11:00 +0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2022-08-24 at 17:29 +0800, Hou Wenlong wrote: > The spte pointing to the children SP is dropped, so the > whole gfn range covered by the children SP should be flushed. > Although, Hyper-V may treat a 1-page flush the same if the > address points to a huge page, it still would be better > to use the correct size of huge page. Also introduce > a helper function to do range-based flushing when a direct > SP is dropped, which would help prevent future buggy use > of kvm_flush_remote_tlbs_with_address() in such case. > > Fixes: c3134ce240eed ("KVM: Replace old tlb flush function with new > one to flush a specified range.") > Suggested-by: David Matlack > Signed-off-by: Hou Wenlong > --- > arch/x86/kvm/mmu/mmu.c | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index e418ef3ecfcb..a3578abd8bbc 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -260,6 +260,14 @@ void kvm_flush_remote_tlbs_with_address(struct > kvm *kvm, > kvm_flush_remote_tlbs_with_range(kvm, &range); > } > > +/* Flush all memory mapped by the given direct SP. */ > +static void kvm_flush_remote_tlbs_direct_sp(struct kvm *kvm, struct > kvm_mmu_page *sp) > +{ > + WARN_ON_ONCE(!sp->role.direct); What if !sp->role.direct? Below flushing sp->gfn isn't expected? but still to do it. Is this operation harmless? > + kvm_flush_remote_tlbs_with_address(kvm, sp->gfn, > + KVM_PAGES_PER_HPAGE(sp- > >role.level + 1)); > +} > + > static void mark_mmio_spte(struct kvm_vcpu *vcpu, u64 *sptep, u64 > gfn, > unsigned int access) > { > @@ -2341,7 +2349,7 @@ static void validate_direct_spte(struct > kvm_vcpu *vcpu, u64 *sptep, > return; > > drop_parent_pte(child, sptep); > - kvm_flush_remote_tlbs_with_address(vcpu->kvm, child- > >gfn, 1); > + kvm_flush_remote_tlbs_direct_sp(vcpu->kvm, child); > } > } >