Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp5122060iog; Wed, 22 Jun 2022 12:28:36 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vuuySxYTFCPvsXvYtNL9vZ7jnMRsJitmWVyeeVdvfBb2YfHSXtKsFh1m4bO5McQA+f5+Yc X-Received: by 2002:a17:90b:1c87:b0:1ca:f4e:4fbe with SMTP id oo7-20020a17090b1c8700b001ca0f4e4fbemr51566862pjb.159.1655926115846; Wed, 22 Jun 2022 12:28:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655926115; cv=none; d=google.com; s=arc-20160816; b=Vzhp9w2nuEwkMqglhSGfRkBsbHRdeBAGVsoxs7WsTwlU6oPp9WhCYBG0Nc9ec+uYOQ CiQn4BNshhQIIjXT9J4qdeG0aaScbr6AAcy5WWLP70YJBTYq9JyNKLqMx6htD5Nbts0L IfYmb6tvHmamg7mjnVSyESZZl/PenvTHBXTZO8lB5lgcGqu2m2T78B9KPLlDeuOWUgSa JMGJ4HOFiJcKSScaOrMhnu4DUqDfbHJ0MayGRUaVptEiNlI5gxT5GrE+smDuXDWyL/9i +VUshejiA3nvvoEDM/VUSWzRYdP3NW9DDZ1YvPz4BtddP5kU+0v+NKbK1yo0Us93GYgH OjMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=UetEegWFrSI4DxaQkVqPZAaYbNMpqePnjSLMmI2uAtM=; b=J8Yb9wJX9JiGVy8ssSfxN6jc5ZQ7sRAhFkevDBOttIXWM0Dqbj64kSRY2pjtYy9OTh Bs1rSiE1xwPM6z26WKxpSZNdfDmNZA6nLITW0ronzo6BeSN0eaFu6rBnGDNXkAB8+2JG qewpT7H5mXCMyox5k8UDr0Sxk7wgPRQaR2Men1Dr8j9sU+SZc/af0BTcjWvUuXitsQu3 WXb/haQNqkxZdkc3CxwmMKqFIftXsGhlLcpuygwxN6nTl9mcMRSIriPEt6RSeI0SDmPZ sH2mK2HsMdPfM9yMWlkIOuVUSDo8h0bgIggRK1ZdXrkZUlFINLbMMRYqUMW7I7ln1kPN 17NA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Kaif2yG8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i136-20020a639d8e000000b003fabebb91b0si24018595pgd.753.2022.06.22.12.28.24; Wed, 22 Jun 2022 12:28:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Kaif2yG8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357215AbiFVT10 (ORCPT + 99 others); Wed, 22 Jun 2022 15:27:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229824AbiFVT1Q (ORCPT ); Wed, 22 Jun 2022 15:27:16 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E27AFDAD for ; Wed, 22 Jun 2022 12:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655926034; 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=UetEegWFrSI4DxaQkVqPZAaYbNMpqePnjSLMmI2uAtM=; b=Kaif2yG83Ff/NpnEo43LLDR6iE+sDojc/nGfkVLBb/ezn+ifyI246VDIb0u8E2nAgn0kz8 +wvR3nZBBA/j62UOZE/uxurXt0tfuoUxnu4NEM5DsZXZaxWb4Y/cqN1RxQ9YBguAeiivPb 5jhXoFI2ZJruEnEJo5pb0BPN7WAtq7o= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-464-nl_lej8DNwCY7ROTjZCaaA-1; Wed, 22 Jun 2022 15:27:12 -0400 X-MC-Unique: nl_lej8DNwCY7ROTjZCaaA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8D5ED102F0C1; Wed, 22 Jun 2022 19:27:11 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 36C8B1121314; Wed, 22 Jun 2022 19:27:11 +0000 (UTC) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: maz@kernel.org, anup@brainfault.org, seanjc@google.com, bgardon@google.com, peterx@redhat.com, maciej.szmigiero@oracle.com, kvmarm@lists.cs.columbia.edu, linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org, pfeiner@google.com, jiangshanlai@gmail.com, dmatlack@google.com Subject: [PATCH v7 01/23] KVM: x86/mmu: Optimize MMU page cache lookup for all direct SPs Date: Wed, 22 Jun 2022 15:26:48 -0400 Message-Id: <20220622192710.2547152-2-pbonzini@redhat.com> In-Reply-To: <20220622192710.2547152-1-pbonzini@redhat.com> References: <20220622192710.2547152-1-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: David Matlack Commit fb58a9c345f6 ("KVM: x86/mmu: Optimize MMU page cache lookup for fully direct MMUs") skipped the unsync checks and write flood clearing for full direct MMUs. We can extend this further to skip the checks for all direct shadow pages. Direct shadow pages in indirect MMUs (i.e. shadow paging) are used when shadowing a guest huge page with smaller pages. Such direct shadow pages, like their counterparts in fully direct MMUs, are never marked unsynced or have a non-zero write-flooding count. Checking sp->role.direct also generates better code than checking direct_map because, due to register pressure, direct_map has to get shoved onto the stack and then pulled back off. No functional change intended. Reviewed-by: Lai Jiangshan Reviewed-by: Sean Christopherson Reviewed-by: Peter Xu Signed-off-by: David Matlack Message-Id: <20220516232138.1783324-2-dmatlack@google.com> Signed-off-by: Paolo Bonzini --- arch/x86/kvm/mmu/mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 27b2a5603496..c0afb4f1c8ae 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -2000,7 +2000,6 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu, int direct, unsigned int access) { - bool direct_mmu = vcpu->arch.mmu->root_role.direct; union kvm_mmu_page_role role; struct hlist_head *sp_list; unsigned quadrant; @@ -2060,7 +2059,8 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct kvm_vcpu *vcpu, continue; } - if (direct_mmu) + /* unsync and write-flooding only apply to indirect SPs. */ + if (sp->role.direct) goto trace_get_page; if (sp->unsync) { -- 2.31.1