Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7470913pxb; Thu, 18 Feb 2021 10:52:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJyFXd9KqAK11/j2LP/ujTlXPJS1MnWnF6OgnjY0s/KmtV5kck5KlidpTZpb6xXZ45tE6jqk X-Received: by 2002:a17:906:c1d9:: with SMTP id bw25mr5343283ejb.452.1613674378650; Thu, 18 Feb 2021 10:52:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613674378; cv=none; d=google.com; s=arc-20160816; b=s1U9Vf5dMu/hO43/CGR5N2tGduPn+dqEXKdY4V/GuozZTm1WwPDmrFrsY/2uSwRj4y uFL9E1yEL9a+UlIIv1L4D0r2S5O00ykFKWVmBR+UMdlugDSqEnEJRgYNLAiwdH3/fzK4 WrB0bURWq4jfDX1AASWEgcLSlzD41UwG9SwCZmb9plluok7BaSQ8fwlLvetkT/8Ha1OO bpS/fTTw2KTPG/H9qV7F9eDIpKezpeTHoTPv3jkB47nvsOg5rgykTXYsTECWetYILc2Z Jq7FTtAZe0RCtDxD9QwwZlsHs0eGo2LrVEOKgHpzIh0n/b+JQDeU5lbGgHw/DuD1Cccc lMcA== 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=DqLb1nMq14/rKI2+/NThAnihxh+nHxjLWJAo5ipH1Ws=; b=jd4+obXGu6Nq/gqA1hxfO1+WMlveGEpnxIN2hLSc5lS2nDATDwAW++mt7sq/z2lcAC ccZn9DoWEWTLYp+smgwu9tWNl9gM7yHg0O9EJDs/MYJB9K7hBx5b8fNPw4mtfc8eQmsu eluOl5VgYEliP/lBEPPeK4wPjdEawwKzoftSxXWVWkJ5x36L6TXPyYCEH5EkevkPQlX4 1PHhZaOgFo9mjF008y3LMo4f4sF9ZIbBXl79xEs115SkBOD9fPS2gsND6hMPvuUE50o3 cfkVwxGfugLxAUisDw5hSQJCFfW75qATVccCr1sU9xxFrnOFTnOqKYFPfCFB7d3X4oyk 5jbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="md44/Px+"; 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 t11si2550053ejt.33.2021.02.18.10.52.32; Thu, 18 Feb 2021 10:52:58 -0800 (PST) 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="md44/Px+"; 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 S233233AbhBRSur (ORCPT + 99 others); Thu, 18 Feb 2021 13:50:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233846AbhBRQoN (ORCPT ); Thu, 18 Feb 2021 11:44:13 -0500 Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83142C061786 for ; Thu, 18 Feb 2021 08:35:42 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id z15so1657281pfc.3 for ; Thu, 18 Feb 2021 08:35:42 -0800 (PST) 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=DqLb1nMq14/rKI2+/NThAnihxh+nHxjLWJAo5ipH1Ws=; b=md44/Px+2SYhg3j59P0MfiNu7AvOT5R8yCXllWmXN1HLCn41bzTgMiigaxhw+qQ3nS 8Vl0kNQwvSu/lWr12I2+sryWC9Xsu5ecLXdqdqfE8/yxOTBGxxFYvHwOS/C84LQ1u0hf mxdFswTZrTeNLMuTMil8ktlWYBYm8nzG8PThHZvZefb2zVMvdI7jbE9Dmrv3KnrTtQwO ueDZbeL2tBuyZrjKpfd8+hyNtYkuUHaM8qtrpQZk7M+r7jiRjRqNA0nm6vz7+uQ4OmnZ bRpUeHSkaUqRPHLH8sp5vDA1/z1wHWhL9iuWOUqh/tsixm5v9XUMFTxxUVMRtOZwWXSe M9ag== 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=DqLb1nMq14/rKI2+/NThAnihxh+nHxjLWJAo5ipH1Ws=; b=btLFu0Ne9Ox1zbCHrGRyqWoIuwAYqw0KYfsoEGEcrvHynyWTTR3yJJ2ihFaa50AbfP 20L0MLm/6csIfEaKuLk49clwkeufLHJzhakUSmo6DncmjjnNoeJYBkCBM4HlYwuJ9qic HxX7393h9Gm1QbOqrvXCFVUemTNJ4MYFdPgy3J0A02uZQZ0/OvPysX7l1YMDykN/gUdB uraUD4hxbUpgOjuyXHUdt3NX7jFJtYET5cC2re0bFvLXFDyVwXmxNBbKgTZRdg96rKmP dLEdjk/aB0rHGcim6qpPTueaeE/JlIAHygXmnioyFPiv+egAQFqyO5lMeTmN1hNUnmwI S42w== X-Gm-Message-State: AOAM5311ZZb4VUsNA5v2BJioa9u/EduB1eJCwalQE9nxFIHY/OItDy0v YNE4vhdny0yoeTkNtOArZ9TSwQ== X-Received: by 2002:a63:214e:: with SMTP id s14mr4641755pgm.101.1613666141653; Thu, 18 Feb 2021 08:35:41 -0800 (PST) Received: from google.com ([2620:15c:f:10:dc76:757f:9e9e:647c]) by smtp.gmail.com with ESMTPSA id q7sm3116401pfb.185.2021.02.18.08.35.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Feb 2021 08:35:40 -0800 (PST) Date: Thu, 18 Feb 2021 08:35:34 -0800 From: Sean Christopherson To: Paolo Bonzini Cc: David Edmondson , linux-kernel@vger.kernel.org, Borislav Petkov , Wanpeng Li , Thomas Gleixner , Ingo Molnar , Vitaly Kuznetsov , x86@kernel.org, "H. Peter Anvin" , kvm@vger.kernel.org, Jim Mattson , Joerg Roedel Subject: Re: [PATCH] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid Message-ID: References: <20210218100450.2157308-1-david.edmondson@oracle.com> <708f2956-fa0f-b008-d3d2-93067f95783c@redhat.com> <8f9d4ef7-ddad-160b-2d94-69f4370e8702@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f9d4ef7-ddad-160b-2d94-69f4370e8702@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 18, 2021, Paolo Bonzini wrote: > On 18/02/21 13:56, David Edmondson wrote: > > On Thursday, 2021-02-18 at 12:54:52 +01, Paolo Bonzini wrote: > > > > > On 18/02/21 11:04, David Edmondson wrote: > > > > When dumping the VMCS, retrieve the current guest value of EFER from > > > > the kvm_vcpu structure if neither VM_EXIT_SAVE_IA32_EFER or > > > > VM_ENTRY_LOAD_IA32_EFER is set, which can occur if the processor does > > > > not support the relevant VM-exit/entry controls. > > > > > > Printing vcpu->arch.efer is not the best choice however. Could we dump > > > the whole MSR load/store area instead? > > > > I'm happy to do that, and think that it would be useful, but it won't > > help with the original problem (which I should have explained more). > > > > If the guest has EFER_LMA set but we aren't using the entry/exit > > controls, vm_read64(GUEST_IA32_EFER) returns 0, causing dump_vmcs() to > > erroneously dump the PDPTRs. > > Got it now. It would sort of help, because while dumping the MSR load/store > area you could get hold of the real EFER, and use it to decide whether to > dump the PDPTRs. EFER isn't guaranteed to be in the load list, either, e.g. if guest and host have the same desired value. The proper way to retrieve the effective EFER is to reuse the logic in nested_vmx_calc_efer(), i.e. look at VM_ENTRY_IA32E_MODE if EFER isn't being loaded via VMCS.