Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5806398pxj; Wed, 23 Jun 2021 09:18:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJysVLuhj6gHBcdmTwOMAAYLWzVbTWIA8EGgTMwc2uAMLXG3kluQJadVWjGHiL9LJJVf5vrG X-Received: by 2002:a17:906:1792:: with SMTP id t18mr874142eje.38.1624465118023; Wed, 23 Jun 2021 09:18:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624465118; cv=none; d=google.com; s=arc-20160816; b=DuMljosSEc/IPi4KXQfU1CD/iH6bRt6hvYAq9JzepAe43QY8brUpfTa0e76QILxR1x mUtKfy9u0kszLlrJNIa1fB8x3YDMu1ZKIL0aVcY1P/FLuZFzqHGKTAQusmsXKpRokkhy zPYZtZaM8GrYWak/NJpT/qdP+gr4GFTFBGWH4raf+/HSjMXSwS7GKlE7qKG9lAqe+t+n ftzNr72f/W9AG50o4saW83GVq0cLhN3XgvpljljbSa6x3ll7uwXMo93ApS1LKTw7cY2e wt1IfHxPJahuypwa1E2Nh/bj9GDXU32g24QldhRFGj4cd6lAV8R9M3ZFygn/cV9R7UWt rFtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=7zn0oCEuocGAdQ6ZsgTeBUSCFiV5Hshm48AY9/StAM4=; b=el276go90z6OrlxdyNITZtiBabHNaSia9YtQLhb7macBySQ9J6oS/VdIa577Ii6dgr 68aUMYGbiB/eDIopRG50nRYvhuICVyRuyQfSelM1rYrB2mupGfH7NkL7sJ8v5Y/UsZxa JmLP1RVzyx3pfoHRel+o0a++yj42vm7DM/TNWQ3aihIacyHoeiGshfFir/ofPtMA7bPC Qqvyle88Ttu9u5Fbh9SAaoMLKy8TWWi4ZZgMwwXZQ24CpGXZHhjlbN//YIKeebH22Usg pPPW39137JKmflgsjrBsUfFLDlPbkY0I9sMuNPVpOOdVCCucfFnFBu8GRd/Y5oJQhWJl Mgmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Nz0Xjy+h; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ce12si125242ejc.456.2021.06.23.09.18.13; Wed, 23 Jun 2021 09:18:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Nz0Xjy+h; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229933AbhFWQTe (ORCPT + 99 others); Wed, 23 Jun 2021 12:19:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229523AbhFWQTa (ORCPT ); Wed, 23 Jun 2021 12:19:30 -0400 Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 54588C061756 for ; Wed, 23 Jun 2021 09:17:11 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id u190so2174924pgd.8 for ; Wed, 23 Jun 2021 09:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=7zn0oCEuocGAdQ6ZsgTeBUSCFiV5Hshm48AY9/StAM4=; b=Nz0Xjy+hjgVfAotFNLUVfPHkM8fT//dLdVyMD2rSuPCq5XlGXdsVfWDftvNwegRi0j QuoHiUC4wWpK8j0CDRqFS1T+cK0RAt8KUHRRNPR9DcBNmJ8rTWtjzAdj7xjQh6jVOqVv 8RGrdSLkvx0n/VS0WKegRt+rFTykf/mHcjkZamF54etoNv82r/4GSu6uyfPSHpIdznQD 2GxNvp9/0v/tcZ2fFeK5Oro2OGcpg7Th3oGhH78UuIIB4KFRfMRjKlMTTL/Tea/t4cUi 74RjXxU6/898atYSMaLd8jV+mTNju5h5f9YH9h6H9kNpbgBodX4ezdGrHWggZTLhSvA3 VLJA== 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=7zn0oCEuocGAdQ6ZsgTeBUSCFiV5Hshm48AY9/StAM4=; b=bPXyBpz/QxFWi3wAHo8aHmMCUH24f0etaodXSJi8K5yqKfnrsoLpmoDYXixTHAIcyK e8QvAP4VgVyG4GXawr+Dzj+a/jNa5RqHXER/BzQZAd2eQOd9A3QuvOfLU4+SXfwNd88M cNwoh1o2itN9ekfur9vPkLonyi8C4iN5CLPX2spK/ShSTfQ5TFVG4LFLFlexdoW0Qai0 PrhEaBPc9DNv2N7LEWioEEnsr/UrlCJKvozaSgM3JJiWQO6Jz3JuzkJZA1TYCaYm7s7S 3h1zoR0hdwNDtYx56Nz56d9GwX7JuiX063ud7EE84SxWgMSTLxxuhh1i4VpZ3Y0f26KE KVFQ== X-Gm-Message-State: AOAM530phY6uAgyxjuGVsG3KATywS7SJHFdOflKnBvRY2DIP6YwmaziP itTMaUWokwthGedVmqXC1uoqew== X-Received: by 2002:a63:464b:: with SMTP id v11mr285761pgk.156.1624465030475; Wed, 23 Jun 2021 09:17:10 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id la18sm3068180pjb.55.2021.06.23.09.17.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Jun 2021 09:17:08 -0700 (PDT) Date: Wed, 23 Jun 2021 16:17:04 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Yu Zhang , Maxim Levitsky Subject: Re: [PATCH 10/54] KVM: x86/mmu: Replace EPT shadow page shenanigans with simpler check Message-ID: References: <20210622175739.3610207-1-seanjc@google.com> <20210622175739.3610207-11-seanjc@google.com> <8ce36922-dba0-9b53-6f74-82f3f68b443c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ce36922-dba0-9b53-6f74-82f3f68b443c@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 23, 2021, Paolo Bonzini wrote: > On 22/06/21 19:56, Sean Christopherson wrote: > > Replace the hack to identify nested EPT shadow pages with a simple check > > that the size of the guest PTEs associated with the shadow page and the > > current MMU match, which is the intent of the "8 bytes == PAE" test. > > The nested EPT hack existed to avoid a false negative due to the is_pae() > > check not matching for 32-bit L2 guests; checking the MMU role directly > > avoids the indirect calculation of the guest PTE size entirely. > > What the commit message doesn't say is, did we miss this opportunity all > along, or has there been a change since commit 47c42e6b4192 ("KVM: x86: > fix handling of role.cr4_pae and rename it to 'gpte_size'", 2019-03-28) > that allows this? The code was wrong from the initial "unsync" commit. The 4-byte vs. 8-byte check papered over the real bug, which was that the roles were not checked for compabitility. I suspect that the bug only manisfested as an observable problem when the GPTE sizes mismatched, thus the PAE check was added. So yes, there was an "opportunity" that was missed all along. > I think the only change needed would be making the commit something like > this: > > ========== > KVM: x86/mmu: Use MMU role to check for matching guest page sizes > > Originally, __kvm_sync_page used to check the cr4_pae bit in the role > to avoid zapping 4-byte kvm_mmu_pages when guest page size are 8-byte > or the other way round. However, in commit 47c42e6b4192 ("KVM: x86: fix > handling of role.cr4_pae and rename it to 'gpte_size'", 2019-03-28) it > was observed that this did not work for nested EPT, where the page table > size would be 8 bytes even if CR4.PAE=0. (Note that the check still > has to be done for nested *NPT*, so it is not possible to use tdp_enabled > or similar). > > Therefore, a hack was introduced to identify nested EPT shadow pages > and unconditionally call __kvm_sync_page() on them. However, it is > possible to do without the hack to identify nested EPT shadow pages: > if EPT is active, there will be no shadow pages in non-EPT format, > and all of them will have gpte_is_8_bytes set to true; we can just > check the MMU role directly, and the test will always be true. > > Even for non-EPT shadow MMUs, this test should really always be true > now that __kvm_sync_page() is called if and only if the role is an > exact match (kvm_mmu_get_page()) or is part of the current MMU context > (kvm_mmu_sync_roots()). A future commit will convert the likely-pointless > check into a meaningful WARN to enforce that the mmu_roles of the current > context and the shadow page are compatible. > ========== > > > Paolo > > > Note, this should be a glorified nop now that __kvm_sync_page() is called > > if and only if the role is an exact match (kvm_mmu_get_page()) or is part > > of the current MMU context (kvm_mmu_sync_roots()). A future commit will > > convert the likely-pointless check into a meaningful WARN to enforce that > > the mmu_roles of the current context and the shadow page are compatible. > > > > Cc: Vitaly Kuznetsov > > Signed-off-by: Sean Christopherson >