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 5CFB4C433EF for ; Thu, 14 Apr 2022 15:06:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240818AbiDNPIz (ORCPT ); Thu, 14 Apr 2022 11:08:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354223AbiDNOzI (ORCPT ); Thu, 14 Apr 2022 10:55:08 -0400 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99F11DBD28 for ; Thu, 14 Apr 2022 07:42:59 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id mp16-20020a17090b191000b001cb5efbcab6so9477722pjb.4 for ; Thu, 14 Apr 2022 07:42:59 -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=qwcuBgImCmXIPh4KovD6yz7yJbjBcIk++srxxrgHoVk=; b=PqcPSgK5KCFX0ypEAiiuQ48djSg+e6hRlUoxyQKm5+csfnsgcYel8pbIACDPKdIjKR iHjm7BMJeqGyI/nEfPUqUFojs9W5pKDLHiOS5tTpfTgnzcLHRbQoPplRp4MSG2FubYVv KJ/sOzMF9j6eDYKI9fm40PvgwjEB8UXsEx0pOCKujwLNY528/tgdDAs2+HcUzJ46A7Mk b9kflZvhS0PZbSS+HVeVy4/Zjud0oNXTtCGCdZ8zs7rXuSahBGjWZIxMibg0vEHnJxav 6HrSLaAsH5Cugsnm62jDxshYpQ46yXTkT2wfGTJk4FYp3Tsukla7/SlJG3Ud0J9oGyjG PSPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qwcuBgImCmXIPh4KovD6yz7yJbjBcIk++srxxrgHoVk=; b=1vHc3gZ+fk63vUgDx9ZjrqgkyHEDofgKCzrTDNY6AusFL5303pGTYffj0SC1lxB259 ggPd5NGmi/XdTxNwRfbGDzZV9nnnw6kFg7l/aBqP0mGP2aLkufAUCkHg/rhTZJkVXT1C xe2wPEYeD7YPXvm9C9rWmrUGeJtWHVj9sTD71v90/fTGT4mHMspu744fp96XiAnq7Zb2 Av7LNxdDpTfysL4r65+hNCVPn6wx1xQevOvUKKM4xxLbx+rHuloZH2lAzmJEENxMeGyB No7dKGpySq0E2N2wvtgu45ex8eyqNupxhxDNwcL+Z0lVLY3wiD89QUIxPsDk405uyN1S LtBA== X-Gm-Message-State: AOAM532PjTyhwOIfRktEihMQ3jdjhwGrn7pAAT6qRjBiC2KSFNdRrgFf fDyOLV7BDP1DZNQkJnK3x1DOX/Mu6+nwrA== X-Google-Smtp-Source: ABdhPJy2PeIS61cClFOl7u9zD2LzLkl4mWHXZ+aCyR9ZnSEJKTwasVdmpha8K+eK6URzneRvPCXonQ== X-Received: by 2002:a17:902:ecc1:b0:158:6e96:83a7 with SMTP id a1-20020a170902ecc100b001586e9683a7mr18008752plh.79.1649947378972; Thu, 14 Apr 2022 07:42:58 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id e12-20020a056a0000cc00b00508343a6f9esm194233pfj.5.2022.04.14.07.42.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Apr 2022 07:42:58 -0700 (PDT) Date: Thu, 14 Apr 2022 14:42:54 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Lai Jiangshan , LKML , kvm@vger.kernel.org, Lai Jiangshan , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , X86 ML , "H. Peter Anvin" , linux-doc@vger.kernel.org Subject: Re: [RFC PATCH V3 3/4] KVM: X86: Alloc role.pae_root shadow page Message-ID: References: <20220330132152.4568-1-jiangshanlai@gmail.com> <20220330132152.4568-4-jiangshanlai@gmail.com> <683974e7-5801-e289-8fa4-c8a8d21ec1b2@redhat.com> <658729a1-a4a1-a353-50d6-ef71e83a4375@redhat.com> <77699a19-65bd-5088-2f25-1be59364f5ee@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77699a19-65bd-5088-2f25-1be59364f5ee@redhat.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, Apr 14, 2022, Paolo Bonzini wrote: > On 4/14/22 13:06, Lai Jiangshan wrote: > > > Right, but then load_pdptrs only needs to zap the page before (or > > > instead of) calling kvm_mmu_free_roots(). > > > > > > > Guest PAE page is write-protected instead now (see patch4) and > > kvm_mmu_pte_write() needs to handle this special write operation > > with respect to sp->pae_off (todo). > > And load_pdptrs() doesn't need to check if the pdptrs are changed. > > Write-protecting the PDPTR page is unnecessary, the PDPTRs cannot change > without another CR3. That should be easy to do in account_shadowed and > unaccount_shadowed Technically that's not true under SVM? Under SVM, however, when the processor is in guest mode with PAE enabled, the guest PDPT entries are not cached or validated at this point, but instead are loaded and checked on demand in the normal course of address translation, just like page directory and page table entries