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.2 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, URIBL_BLOCKED,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 3BF0AC433E6 for ; Tue, 23 Feb 2021 23:30:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0272864E77 for ; Tue, 23 Feb 2021 23:30:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232715AbhBWX31 (ORCPT ); Tue, 23 Feb 2021 18:29:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233148AbhBWXTu (ORCPT ); Tue, 23 Feb 2021 18:19:50 -0500 Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16BFDC061786 for ; Tue, 23 Feb 2021 15:19:07 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id c16so420315otp.0 for ; Tue, 23 Feb 2021 15:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dRXoBDgFZIgD9+/8HNqkE5zY8pCw7BmfPg5XxXSAbIs=; b=mVKXk2bMH060FPg+WmGqt0nUnrkjnTuiNcf0GH2M4keakiQ6qIkznBVX4NBwGN4bhN qI5bpffiHUxCSNtJqjIuq9tBlnWoGwo9XCLz2hdCQHOwScpeaSqCxez1KiVINyzV0Bmx bIWqfiHiwP8HApIl5As5mecCbqim9KRpJ8Horkb+EUH2zN3tusxExi8ISutmVS8DxGuA vAhGWXCkNtiiBOrI3kVKgMTCZ39l7hYDbphinX2jOuTEy7RVsiqSK5vlWVg9jW+qqKvF 3WeUinQSL39T5HNH8K1G1ewfLibgnwz4U3RPneBr9EAIkoaBPBe9sfiAHQB3x84G1zW4 +5zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dRXoBDgFZIgD9+/8HNqkE5zY8pCw7BmfPg5XxXSAbIs=; b=tVoV0Drw73azKtDrss+eMl4bryqotjkgO+uHZwRn4qBCmOsSsnSBAjbwtCKLwLTSjU dvbpx+aknBoC2H7RjJEWajwchr5jwt0hwX1+ktrdhxKIV/F7X9CpKNl7y0ndx8MTx3+V 0DrSiQQnX4+BxDlfiFEWB9C2k4mZycg6IAy9QProNus2cNqKNs60eNwurN0GwAdQhaBO 1BS4rbjM/UF3IhXdgJg6/Dtlli9zw1D3arbeMGkRBirV5XkpJeCH8p7oc39uvxW3fYlB FkuTIfK5/xVPoZtPXdmc3iPNtgo5BfprZE25cVT2xfdfBh+XbPsGds0yj4sd+jt1CmxM F4pA== X-Gm-Message-State: AOAM533Xa1R/ichSg90d96yTXbT4qZ6G3vyCMay4C6mLCCNNnpr4ihuA xXTuOoD7KVeoiPsGLC8lUksGOxcVo9mytidApbdoPA== X-Google-Smtp-Source: ABdhPJwKP4y+pemw61s5TPgupsrWMV3z9RQT2hiO6PBkW7Y2Z/NK3FR+aq2pE5vF0aYfenU9TlzVP4y+Z/XB4dnWHd8= X-Received: by 2002:a05:6830:c9:: with SMTP id x9mr3343269oto.295.1614122346158; Tue, 23 Feb 2021 15:19:06 -0800 (PST) MIME-Version: 1.0 References: <20210219144632.2288189-1-david.edmondson@oracle.com> <20210219144632.2288189-2-david.edmondson@oracle.com> In-Reply-To: <20210219144632.2288189-2-david.edmondson@oracle.com> From: Jim Mattson Date: Tue, 23 Feb 2021 15:18:54 -0800 Message-ID: Subject: Re: [PATCH v2 1/3] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid To: David Edmondson Cc: LKML , "H. Peter Anvin" , Joerg Roedel , "the arch/x86 maintainers" , Thomas Gleixner , kvm list , Paolo Bonzini , Wanpeng Li , Ingo Molnar , Sean Christopherson , Borislav Petkov , Vitaly Kuznetsov Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 19, 2021 at 6:46 AM David Edmondson wrote: > > If the VM entry/exit controls for loading/saving MSR_EFER are either > not available (an older processor or explicitly disabled) or not > used (host and guest values are the same), reading GUEST_IA32_EFER > from the VMCS returns an inaccurate value. > > Because of this, in dump_vmcs() don't use GUEST_IA32_EFER to decide > whether to print the PDPTRs - do so if the EPT is in use and CR4.PAE > is set. > > Fixes: 4eb64dce8d0a ("KVM: x86: dump VMCS on invalid entry") > Signed-off-by: David Edmondson > --- > arch/x86/kvm/vmx/vmx.c | 8 +++----- > 1 file changed, 3 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index eb69fef57485..818051c9fa10 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -5759,7 +5759,6 @@ void dump_vmcs(void) > u32 vmentry_ctl, vmexit_ctl; > u32 cpu_based_exec_ctrl, pin_based_exec_ctrl, secondary_exec_control; > unsigned long cr4; > - u64 efer; > > if (!dump_invalid_vmcs) { > pr_warn_ratelimited("set kvm_intel.dump_invalid_vmcs=1 to dump internal KVM state.\n"); > @@ -5771,7 +5770,6 @@ void dump_vmcs(void) > cpu_based_exec_ctrl = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL); > pin_based_exec_ctrl = vmcs_read32(PIN_BASED_VM_EXEC_CONTROL); > cr4 = vmcs_readl(GUEST_CR4); > - efer = vmcs_read64(GUEST_IA32_EFER); > secondary_exec_control = 0; > if (cpu_has_secondary_exec_ctrls()) > secondary_exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL); > @@ -5784,8 +5782,7 @@ void dump_vmcs(void) > cr4, vmcs_readl(CR4_READ_SHADOW), vmcs_readl(CR4_GUEST_HOST_MASK)); > pr_err("CR3 = 0x%016lx\n", vmcs_readl(GUEST_CR3)); > if ((secondary_exec_control & SECONDARY_EXEC_ENABLE_EPT) && > - (cr4 & X86_CR4_PAE) && !(efer & EFER_LMA)) > - { > + (cr4 & X86_CR4_PAE)) { Assuming that we really want to restrict the printing of the PDPTEs, I think you also need to test "cr0 & CR0.PG" (cf. section 26.3.1.6 of the SDM, volume 3).