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 CF9BAC46467 for ; Thu, 14 Apr 2022 15:45:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358671AbiDNPmG (ORCPT ); Thu, 14 Apr 2022 11:42:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38404 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354224AbiDNOzI (ORCPT ); Thu, 14 Apr 2022 10:55:08 -0400 Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AC1DDBD29 for ; Thu, 14 Apr 2022 07:42:59 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id i24-20020a17090adc1800b001cd5529465aso4791564pjv.0 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=NxLFkKLZzIdiil1t9OutSKP4mI2mDNwI0OFDo28JZc5X1jCrdPDHU3vmIlyJw/+HYn gBhQXtvZnKHIwZsfaGC+tr4DHRzIlrR30jOUhXNrcdtkmHIMrbnUTyo6jAL/TyVRjQ4Q 6BlUMLzT7x0N+N4xF2pYFE9Rec0fKSy07FTl9HJ4kk3Zri5f4GHiu9FJsZC+Ci830/Db aI4gMJYtdIuO/RE0UhMj4h4ffvFVwk1f7QtnstQ7W9K+lb3+Xs5R2OjDy00UFzDF5ZRP 0wruWnBwL2umhbRDgXli6WSbupgMLqGvX6sCF9dJ4hcdlkvg6nyksl3cndVGiIs0rdUs 3pJg== X-Gm-Message-State: AOAM532fN/+ErPUjGtdOWhKbhi8Ccp2DsqEZJDkaAwrlfc5a1Jfu2IMb AVXp8Luu1KWG0mm5BKW/YpMp5g== 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: linux-kernel@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