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 X-Spam-Level: X-Spam-Status: No, score=-18.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5EE95C433EF for ; Fri, 3 Sep 2021 16:40:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4228F610CF for ; Fri, 3 Sep 2021 16:40:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350115AbhICQlf (ORCPT ); Fri, 3 Sep 2021 12:41:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41046 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350087AbhICQle (ORCPT ); Fri, 3 Sep 2021 12:41:34 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F145C061757 for ; Fri, 3 Sep 2021 09:40:34 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id f11-20020a17090aa78b00b0018e98a7cddaso4253164pjq.4 for ; Fri, 03 Sep 2021 09:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=v5OTz7CnUkUM4eY5RTrhL/SW/NS0L0zb0w5yqF65JVM=; b=TPqUlE4vsj+zKa7HaWHKFrNz4FHIDAn1VSWdoDtvPEYoXf8j3FIgsnR9twTb/N5pvj hochQfiLmdYN9NkKeXN4J5YW4AwswTucve/tJoQVMtSdc6n+ApiJjtY9Stv1H5QKuwMl DRyAt5+yL8yNcb2k/HwRTL2qQuQAJt12PxlkYk9V599GuhEM2h0sIpDsW5qn5UOVrr7a JAUb+3M0HiCXbmMG42WsDG5DEAaRt09k0ej41GT+dO3gP0YGIBJysnKpAsZbif1xSX9m 6knaPBoT/qU9Z0sqi7JvzIcCHgFHwroV+8FKRN8opAhREhMw/zdgbmTFH+SDkWDIMqCR YlXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=v5OTz7CnUkUM4eY5RTrhL/SW/NS0L0zb0w5yqF65JVM=; b=oLR6DMrcNtnkvlktKchROcrCDX0A8LU6ofNAky9oRYdtn1DzLgmdAc34vlDcwWo0gb ZcQiYk3LG2TT0fvJ9thi/C5YRR+2X3fVDqE4M1La+2Bm1dwA7v78um3aSP8OoNAweosU xWGjl+3tEmacSfE7M1uqnN0BmyijPjjfKH8bz8eBwcvy8oloyrYfnAWCeBPjMYtcWPxy 5wRjHVcCySDuMc/RkpPqrbrMDVEDXTfTbX7Ymm1XHfoyTsLC8oTD/p58tWOy+5HuruOP cRStfZXQ3QVJdEWeWsXNrzTPrVe4WwM18+7oZsPGXdOQ/Pi6r5u3Dds6SEbvSzl6Vhz0 J/HQ== X-Gm-Message-State: AOAM532ivF/o9UucOu7EMujbmI65cRL5QmQnk5hNoWeqcc7w5YL3UtAr 8qWWS2+cR1sw0SEjIJIV8frRYg== X-Google-Smtp-Source: ABdhPJxsfc197jHbkx9JBnIoZeZb7rt2Q3NxA6CZylwJ388qYtxJuIhXoOH46UfW/xmk11ye2Ag/Sg== X-Received: by 2002:a17:90a:55cb:: with SMTP id o11mr1730087pjm.244.1630687233610; Fri, 03 Sep 2021 09:40:33 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id gd14sm5751960pjb.49.2021.09.03.09.40.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Sep 2021 09:40:32 -0700 (PDT) Date: Fri, 3 Sep 2021 16:40:29 +0000 From: Sean Christopherson To: Lai Jiangshan Cc: Lai Jiangshan , linux-kernel@vger.kernel.org, Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Marcelo Tosatti , Avi Kivity , kvm@vger.kernel.org Subject: Re: [PATCH 2/7] KVM: X86: Synchronize the shadow pagetable before link it Message-ID: References: <20210824075524.3354-1-jiangshanlai@gmail.com> <20210824075524.3354-3-jiangshanlai@gmail.com> <7067bec0-8a15-1a18-481e-e2ea79575dcf@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7067bec0-8a15-1a18-481e-e2ea79575dcf@linux.alibaba.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 04, 2021, Lai Jiangshan wrote: > > On 2021/9/4 00:06, Sean Christopherson wrote: > > > diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h > > index 50ade6450ace..2ff123ec0d64 100644 > > --- a/arch/x86/kvm/mmu/paging_tmpl.h > > +++ b/arch/x86/kvm/mmu/paging_tmpl.h > > @@ -704,6 +704,9 @@ static int FNAME(fetch)(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault, > > access = gw->pt_access[it.level - 2]; > > sp = kvm_mmu_get_page(vcpu, table_gfn, fault->addr, > > it.level-1, false, access); > > + if (sp->unsync_children && > > + mmu_sync_children(vcpu, sp, false)) > > + return RET_PF_RETRY; > > It was like my first (unsent) fix. Just return RET_PF_RETRY when break. > > And then I thought that it'd be better to retry fetching directly rather than > retry guest when the conditions are still valid/unchanged to avoid all the > next guest page walking and GUP(). Although the code does not check all > conditions such as interrupt event pending. (we can add that too) But not in a bug fix that needs to go to stable branches. > I think it is a good design to allow break mmu_lock when mmu is handling > heavy work. I don't disagree in principle, but I question the relevance/need. I doubt this code is relevant to nested TDP performance as hypervisors generally don't do the type of PTE manipulations that would lead to linking an existing unsync sp. And for legacy shadow paging, my preference would be to put it into maintenance-only mode as much as possible. I'm not dead set against new features/functionality for shadow paging, but for something like dropping mmu_lock in the page fault path, IMO there needs to be performance numbers to justify such a change.