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 2AEC1C433EF for ; Wed, 23 Feb 2022 16:33:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242812AbiBWQdb (ORCPT ); Wed, 23 Feb 2022 11:33:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230215AbiBWQd2 (ORCPT ); Wed, 23 Feb 2022 11:33:28 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 746194CD78 for ; Wed, 23 Feb 2022 08:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645633979; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eJFcVMvv6yQets9GHtEootWOFNlstKVit+WEDgtDqA8=; b=GwkIIkCyotnKLYkshTr7wdSrsIKuAG3Ocw016VsP6ePoloWluHd6me0OAnkDcs9rN6j1jj QX+aQORNhoWbsw6pZdplWXAx18uCgQLCN+FXxNFGszGlcb0vSY3OfF7gNYAi9qUwsOrGOg ioce9hUFvgk6knU9s6kwZLgTGa7TFNQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-57-k7jpMBl1Psy5uqDeQ85eJQ-1; Wed, 23 Feb 2022 11:32:56 -0500 X-MC-Unique: k7jpMBl1Psy5uqDeQ85eJQ-1 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3D15B801AAD; Wed, 23 Feb 2022 16:32:55 +0000 (UTC) Received: from starship (unknown [10.40.195.190]) by smtp.corp.redhat.com (Postfix) with ESMTP id D65DB2ED8D; Wed, 23 Feb 2022 16:32:53 +0000 (UTC) Message-ID: <7f18cfd048609276cc298dbfa01628bd2fa15937.camel@redhat.com> Subject: Re: [PATCH v2 12/18] KVM: x86/mmu: clear MMIO cache when unloading the MMU From: Maxim Levitsky To: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com Date: Wed, 23 Feb 2022 18:32:52 +0200 In-Reply-To: <20220217210340.312449-13-pbonzini@redhat.com> References: <20220217210340.312449-1-pbonzini@redhat.com> <20220217210340.312449-13-pbonzini@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2022-02-17 at 16:03 -0500, Paolo Bonzini wrote: > For cleanliness, do not leave a stale GVA in the cache after all the roots are > cleared. In practice, kvm_mmu_load will go through kvm_mmu_sync_roots if > paging is on, and will not use vcpu_match_mmio_gva at all if paging is off. > However, leaving data in the cache might cause bugs in the future. > > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/mmu/mmu.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c > index b01160716c6a..4e8e3e9530ca 100644 > --- a/arch/x86/kvm/mmu/mmu.c > +++ b/arch/x86/kvm/mmu/mmu.c > @@ -5111,6 +5111,7 @@ void kvm_mmu_unload(struct kvm_vcpu *vcpu) > { > __kvm_mmu_unload(vcpu->kvm, &vcpu->arch.root_mmu); > __kvm_mmu_unload(vcpu->kvm, &vcpu->arch.guest_mmu); > + vcpu_clear_mmio_info(vcpu, MMIO_GVA_ANY); > } > > static bool need_remote_flush(u64 old, u64 new) One thing that bothers me for a while with all of this is that vcpu->arch.{mmio_gva|mmio_access|mmio_gfn|mmio_gen} are often called mmio cache, while we also install reserved bit SPTEs and also call this a mmio cache. The above is basically a cache of a cache sort of. Reviewed-by: Maxim Levitsky Best regards, Maxim Levitsky