Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1054989rwb; Wed, 14 Dec 2022 06:08:10 -0800 (PST) X-Google-Smtp-Source: AA0mqf6dC7Tqg6zxnNQVikKWQtMnTLsJD8BFCiYOrG/W2G0QxvBMjiQC9f9cLX9bqluVSwnNHE+4 X-Received: by 2002:a17:906:fac5:b0:7c1:277:cb05 with SMTP id lu5-20020a170906fac500b007c10277cb05mr21232275ejb.6.1671026890052; Wed, 14 Dec 2022 06:08:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671026890; cv=none; d=google.com; s=arc-20160816; b=icKtZMbVlMiEVglcbs+CbRzZ4Au7Zq5joe+eIx+doLNbev6P1FE0uUFREwU8F5c4Pa uAfH0WXGka8WamQWl+VpHXPOFbEfwrKsIU3P2Rj4v8TCgJ+NONmpzddyDWnXeMe6L3Zf 8PFrbkKnw83e9v/pzpi0rw7GOycTN+W29u7OrqqzoMmc8LeWSqmkFHIRi4qcyA5YHL/a nYnWEX2JdtgABQx79ej4RykZNPrHX308ect6TzojLPuTopd29AmiP4flPowATlW6aTR+ V/DPebYB8TtXpicuDUo2VglDZlq3m3Ah5O8mJSKy1NBrbEc5cq9XPT26SrTSVF3C1OBa 9e3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=/9eqK/hjcD9Lg4iWqN5uvayjQEDXlG4BGCPiAhKd3a0=; b=M+hbl5JnIo/+btKGBHQnM24TP08zLlBWU2Cs0tuh4BJ0WmmSCkvYLK3awerqdbGDCB FLvk8R4WURedG3xdnlJmsjsGshdKZRIQpBlg3eY0/EQI2GOQ3U3rRsIZWObMQIceBqN0 P1SWJkoYAhYITgCv3gRaR+dMt1JAM3+VGpE7j3rpRI0yNIdH6u2OHQfdY3eHgVxfdkJb 6vvTirGpy7/JJSvcrq6eB3e+S0OyUwRusrHlNm9r2PKG89Lax2TRRQOBF2ybHd98Ex+H D3g3K9dSbqjTEsu5zHXoH44bHVTrOPumlUaDD+1w0uUXUHIjkAvqSz/uu1Kwi5ZrQu6x jlNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=eA5yAh3Z; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id nd33-20020a17090762a100b007c0a2472f02si11705130ejc.626.2022.12.14.06.07.52; Wed, 14 Dec 2022 06:08:10 -0800 (PST) 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=@gmail.com header.s=20210112 header.b=eA5yAh3Z; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237708AbiLNNsL (ORCPT + 69 others); Wed, 14 Dec 2022 08:48:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238412AbiLNNsI (ORCPT ); Wed, 14 Dec 2022 08:48:08 -0500 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 62DC5264A6; Wed, 14 Dec 2022 05:48:07 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id w23so3338442ply.12; Wed, 14 Dec 2022 05:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/9eqK/hjcD9Lg4iWqN5uvayjQEDXlG4BGCPiAhKd3a0=; b=eA5yAh3ZPPNxHpT8QpRDYZ/AqfNsbAyuujrUszAcxrb6/+oCDIeFP0+ZwPduui0Olx URIe+QKJUx5OtGDzpgp3SXfJKk80DZgp26B2fFoCv8KI6NCn1gOLsLOTLJJ78s6MhWWL eGEy5Nuk8w2dab03gaS5d1ts+ZgJLMATwS3f+Ij9mXzhRr44wiSBp0IPq1jFS/kvYZDg sI/aK08w1535H1wYHwbuCvxJMNhtwdpoKCnMO3rkdmlBem9oHgtxlXwmJYtW79cP3Rk/ rT8UkVN0TtHK5sWE+Ez0FJWdl0x9kTTKBgBW0g1qap+7Ap1SlFePaEgwXi1IDCJzXQFS 1gdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/9eqK/hjcD9Lg4iWqN5uvayjQEDXlG4BGCPiAhKd3a0=; b=ZpoMiZFSalYl4Y8CcsHsBoZi7OGWEtVrPbWm2gGK9DbFdKK/g3eejOsEohL79BXtoN +oNEjuiEMdFUXzs4fym1lJ+i9JRHjyk0GFRjC6Y1OW4bSQMUGwCV+5cfd/orI+4LGhld 0m8zyW44Mlq+UzrA6YI+2RYqKp76fLnYLZEb4bD2geFP5SlbgUtZiRpliD+UAVbcuzWH JqxD0fHfwilIHsvQ0mwdU53ZlqMzz6/jgL3GE0Xgq6q65vG9CcwP0Yl4k8ezfmkIDBE9 G4fie515eph5d+AHOR1ogYV3Yg4L/HhXkXMvP2f1eRwNvqQkJsDdYP5p/Ob7z9vN8WtH SFwA== X-Gm-Message-State: ANoB5plZ4uDM09XSfifDUrYPHivJR94HGaekL89uUa+ZGmRPeSFlxSwz ++UNSNbrUWF4G3UScRd2qmJ05M0QCT0d6NWWCTw= X-Received: by 2002:a17:902:d510:b0:186:b137:4b42 with SMTP id b16-20020a170902d51000b00186b1374b42mr6292205plg.98.1671025686835; Wed, 14 Dec 2022 05:48:06 -0800 (PST) MIME-Version: 1.0 References: <20221212153205.3360-1-jiangshanlai@gmail.com> <20221212153205.3360-2-jiangshanlai@gmail.com> In-Reply-To: From: Lai Jiangshan Date: Wed, 14 Dec 2022 21:47:55 +0800 Message-ID: Subject: Re: [PATCH 1/2] kvm: x86/mmu: Reduce the update to the spte in FNAME(sync_page) To: Sean Christopherson Cc: linux-kernel@vger.kernel.org, Paolo Bonzini , Lai Jiangshan , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , kvm@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS 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 Hello Sean, On Wed, Dec 14, 2022 at 2:12 AM Sean Christopherson wrote: > > On Mon, Dec 12, 2022, Lai Jiangshan wrote: > > From: Lai Jiangshan > > > > Sometimes when the guest updates its pagetable, it adds only new gptes > > to it without changing any existed one, so there is no point to update > > the sptes for these existed gptes. > > > > Also when the sptes for these unchanged gptes are updated, the AD > > bits are also removed since make_spte() is called with prefetch=true > > which might result unneeded TLB flushing. > > If either of the proposed changes is kept, please move this to a separate patch. > Skipping updates for PTEs with the same protections is separate logical change > from skipping updates when making the SPTE writable. > > Actually, can't we just pass @prefetch=false to make_spte()? FNAME(prefetch_invalid_gpte) > has already verified the Accessed bit is set in the GPTE, so at least for guest > correctness there's no need to access-track the SPTE. Host page aging is already > fuzzy so I don't think there are problems there. FNAME(prefetch_invalid_gpte) has already verified the Accessed bit is set in the GPTE and FNAME(protect_clean_gpte) has already verified the Dirty bit is set in the GPTE. These are only for guest AD bits. And I don't think it is a good idea to pass @prefetch=false to make_spte(), since the host might have cleared AD bit in the spte for aging or dirty-log, The AD bits in the spte are better to be kept as before. Though passing @prefetch=false would not cause any correctness problem in the view of maintaining guest AD bits. > > > Do nothing if the permissions are unchanged or only write-access is > > being added. > > I'm pretty sure skipping the "make writable" case is architecturally wrong. On a > #PF, any TLB entries for the faulting virtual address are required to be removed. > That means KVM _must_ refresh the SPTE if a vCPU takes a !WRITABLE fault on an > unsync page. E.g. see kvm_inject_emulated_page_fault(). I might misunderstand what you meant or I failed to connect it with the SDM properly. I think there is no #PF here. And even if the guest is requesting writable, the hypervisor is allowed to set it non-writable and prepared to handle it in the ensuing write-fault. Skipping to make it writable is a kind of lazy operation and considered to be "the hypervisor doesn't grant the writable permission for a period before next write-fault". Thanks Lai