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 215A5C3527C for ; Thu, 14 Apr 2022 15:45:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358857AbiDNPmV (ORCPT ); Thu, 14 Apr 2022 11:42:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245732AbiDNPMT (ORCPT ); Thu, 14 Apr 2022 11:12:19 -0400 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 17BD51CB1C for ; Thu, 14 Apr 2022 07:52:41 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id t12so4830897pll.7 for ; Thu, 14 Apr 2022 07:52:41 -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=VCv1DBjrR+kR8Ru17MDGLWUciKdYdv1uzvwnzOqdHPk=; b=YmPLuDxX9JQeZXfBU0IrSRbSmP5EHYzXXqteBEfXvYfoTmcfXpqI7aWfAzynwoUKZs RzrbbL0w6vlBfc3eK9R/Agv5xDz0ss/H4yJROYWUD18FQz4VjxbMc2/h30OCodc7TIU6 JWQFC+GRfNgeFGrfsnc4v6jpAei4jKZzOGky1xFSS8fEaCRz4eG8Q5r29AFiAFG0Myad X6JwwWuBxra6BrsEIyZqEDbHojwLopPKXkHTSWlBbcTKwqGIChVgQYSImzfUUAPTusOF xscF4iZir3RKk1MxmvRmEdx46MbnEXU+mhEPGL5QHQ61gVViN5Sa7eJWoYEYY3felkDR 2SBA== 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=VCv1DBjrR+kR8Ru17MDGLWUciKdYdv1uzvwnzOqdHPk=; b=qPIoXdWsWyGlKNc5xPpqFRskeIC4MAq4NV5FDRUbLj4k2qsZV8y9Yg7Xpz/klGHBFx yswYmxKywNmlT0vCeFbUTN2+Jcen82ri0xxztptMNYCm6fdCN6OInNCWHxtCUvJ1GidA rKhuCg8aYNvDLroLJalsFJ7/8jgeHuWcF0IlgVLVIunAKmD7Hxfi3CsC1FaFMvl0vpHa bXi/DBEpc3sQa7x8TB6xOJ1g+KtrJswTL8M+l/SnilALz4MQgy3CZAjAWa2CCUObAghz C8JKfnFyDZdWCGgHW9JTdA84S7cd3KzjxSTHgSvd9HMaXXeCgNRl+9jO0mc28aGoYvmd T3cg== X-Gm-Message-State: AOAM5335l5c1lmqJs3k58VcwJlkkEPB6HCt9u4vqb0rEIL6Ksm5Ga1Dg bu8fie9PPGx+8foem+iALmyaHg== X-Google-Smtp-Source: ABdhPJziYhacBkhotKSQYbGP23a9zbaCkxbZmGj3QOSR1uBcyFUC7gRfTpS1WyPtRILk4lB4cHCmWg== X-Received: by 2002:a17:90b:3b89:b0:1c6:56a2:1397 with SMTP id pc9-20020a17090b3b8900b001c656a21397mr4113040pjb.239.1649947960320; Thu, 14 Apr 2022 07:52:40 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id w14-20020a17090a4f4e00b001cb510021ecsm6116472pjl.49.2022.04.14.07.52.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Apr 2022 07:52:38 -0700 (PDT) Date: Thu, 14 Apr 2022 14:52:35 +0000 From: Sean Christopherson To: Lai Jiangshan Cc: LKML , kvm@vger.kernel.org, Paolo Bonzini , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 14, 2022, Lai Jiangshan wrote: > On Wed, Apr 13, 2022 at 5:14 AM Sean Christopherson wrote: > > > > On Wed, Mar 30, 2022, Lai Jiangshan wrote: > > > From: Lai Jiangshan > > > > > > Currently pae_root is special root page, this patch adds facility to > > > allow using kvm_mmu_get_page() to allocate pae_root shadow page. > > > > I don't think this will work for shadow paging. CR3 only has to be 32-byte aligned > > for PAE paging. Unless I'm missing something subtle in the code, KVM will incorrectly > > reuse a pae_root if the guest puts multiple PAE CR3s on a single page because KVM's > > gfn calculation will drop bits 11:5. > > I forgot about it. > > > > > Handling this as a one-off is probably easier. For TDP, only 32-bit KVM with NPT > > benefits from reusing roots, IMO and shaving a few pages in that case is not worth > > the complexity. > > > > I liked the one-off idea yesterday and started trying it. > > But things were not going as smoothly as I thought. There are too > many corner cases to cover. Maybe I don't get what you envisioned. Hmm, I believe I was thinking that each vCPU could have a pre-allocated pae_root shadow page, i.e. keep pae_root, but make it struct kvm_mmu_page pae_root; The alloc/free paths would still need special handling, but at least in theory, all other code that expects root a shadow page will Just Work.