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 X-Spam-Level: X-Spam-Status: No, score=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46D88C433B4 for ; Thu, 22 Apr 2021 16:15:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 23F1361422 for ; Thu, 22 Apr 2021 16:15:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237927AbhDVQPt (ORCPT ); Thu, 22 Apr 2021 12:15:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235232AbhDVQPs (ORCPT ); Thu, 22 Apr 2021 12:15:48 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55E12C06138B for ; Thu, 22 Apr 2021 09:15:12 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id t22so23457250ply.1 for ; Thu, 22 Apr 2021 09:15:12 -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=hPrnw+6gYREfgVmbG9la+vlv6dGyfI3xfHXyLaBNaY0=; b=gScS+XjDdPxVnNlif6QF4Ktr6IKwhe4aH5TJDc6JBaZWQ2DitrRN8UJvq/dfOzR3DW ovBVyy6Gxt0d3lGIoRzMFZH8FYMUXylkFbEjmxwf34wbaWdzDaDBYeRPjN2YUYgQi6uC Srkldqp9AkSmKS2B0oY6zw+WrWSPFlxwVmfNI3r8ogY5WLnqS83VfFVc3/c/P8/aa9tQ yzFBJCmdtRrmq3QmKB/eeLiiLCFbAVwsKJ4cY6aW4mz5w4F+Zw4ElhKDREydU31wRTCz Y9Sf/N88Va6bZme1WGuaPYig4QnkAR4VXy+8/W7y+/DPmQ1r1sCTmEMxQnvMJQOIx22R vFFg== 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=hPrnw+6gYREfgVmbG9la+vlv6dGyfI3xfHXyLaBNaY0=; b=FtKFVmQHQoRcmPnkYSf1bgzd202j/Rf2bbIv7NOioqb0m7dAAkbyfGYIS7S8zRRawq mey8WabM+iPdS8SsOYCc/yIzXxbLObsi2T1MS1ivvbxVe7gctXX+/f5qTkF/80udmgme Uf3KZgaSDEejA3CWeWNMoDf1Vq3NtgDmS3utrERs8tZdVZHa1DYqTFS2gnIfNGGDn5o8 /u4d8JvUJm7cT0nbJLu0OI42WCRlMbju/sSn65QItU8fwO/e7+ExNU6nkLCJEP0PfNVq LxZjexZtv53Sp4wHp5XTUnrUjAeO57Y/OY0h3mFl/K8191QKQns7NzAdGKyviOPe0jnZ RQng== X-Gm-Message-State: AOAM530iIh3DF0OpR4zm9yGPKwFVtD/LBshzIOnXsr0MDtKTD8Hks3+8 0PNrFNbILJQkKc/slsLWmlvo1A== X-Google-Smtp-Source: ABdhPJyOayWFoLYWFT+Owff0/VHBrm9ci9acPCP3tukyJz3F7vgvr3XujaCyYBh0KIO5KKe033tbBg== X-Received: by 2002:a17:902:b117:b029:e6:81ed:8044 with SMTP id q23-20020a170902b117b02900e681ed8044mr4092540plr.13.1619108111612; Thu, 22 Apr 2021 09:15:11 -0700 (PDT) Received: from google.com (240.111.247.35.bc.googleusercontent.com. [35.247.111.240]) by smtp.gmail.com with ESMTPSA id h8sm2693759pjt.17.2021.04.22.09.15.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Apr 2021 09:15:11 -0700 (PDT) Date: Thu, 22 Apr 2021 16:15:07 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , Wei Huang , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Borislav Petkov , Tom Lendacky , Brijesh Singh Subject: Re: [PATCH v5 03/15] KVM: SVM: Disable SEV/SEV-ES if NPT is disabled Message-ID: References: <20210422021125.3417167-1-seanjc@google.com> <20210422021125.3417167-4-seanjc@google.com> <5e8a2d7d-67de-eef4-ab19-33294920f50c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5e8a2d7d-67de-eef4-ab19-33294920f50c@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 22, 2021, Paolo Bonzini wrote: > On 22/04/21 04:11, Sean Christopherson wrote: > > Disable SEV and SEV-ES if NPT is disabled. While the APM doesn't clearly > > state that NPT is mandatory, it's alluded to by: > > > > The guest page tables, managed by the guest, may mark data memory pages > > as either private or shared, thus allowing selected pages to be shared > > outside the guest. > > > > And practically speaking, shadow paging can't work since KVM can't read > > the guest's page tables. > > > > Fixes: e9df09428996 ("KVM: SVM: Add sev module_param") > > Cc: Brijesh Singh > Cc: Tom Lendacky > > Signed-off-by: Sean Christopherson > > --- > > arch/x86/kvm/svm/svm.c | 30 +++++++++++++++--------------- > > 1 file changed, 15 insertions(+), 15 deletions(-) > > > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > > index fed153314aef..0e8489908216 100644 > > --- a/arch/x86/kvm/svm/svm.c > > +++ b/arch/x86/kvm/svm/svm.c > > @@ -970,7 +970,21 @@ static __init int svm_hardware_setup(void) > > kvm_enable_efer_bits(EFER_SVME | EFER_LMSLE); > > } > > - if (IS_ENABLED(CONFIG_KVM_AMD_SEV) && sev) { > > + /* > > + * KVM's MMU doesn't support using 2-level paging for itself, and thus > > + * NPT isn't supported if the host is using 2-level paging since host > > + * CR4 is unchanged on VMRUN. > > + */ > > + if (!IS_ENABLED(CONFIG_X86_64) && !IS_ENABLED(CONFIG_X86_PAE)) > > + npt_enabled = false; > > Unrelated, but since you're moving this code: should we be pre-scient and > tackle host 5-level paging as well? > > Support for 5-level page tables on NPT is not hard to fix and could be > tested by patching QEMU. However, the !NPT case would also have to be fixed > by extending the PDP and PML4 stacking trick to a PML5. Isn't that backwards? It's the nested NPT case that requires the stacking trick. When !NPT is disabled in L0 KVM, 32-bit guests are run with PAE paging. Maybe I'm misunderstanding what you're suggesting. > However, without real hardware to test on I'd be a bit wary to do it. > Looking at 5-level EPT there might be other issues (e.g. what's the guest > MAXPHYADDR) and I would prefer to see what AMD comes up with exactly in the > APM. So I would just block loading KVM on hypothetical AMD hosts with > CR4.LA57=1. Agreed, I think blocking KVM makes the most sense.