Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7486737pxb; Thu, 18 Feb 2021 11:18:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJzSNwV4zS2WX2ca4jqZAvrP/cfx1Ewv3XsPGdPMDqne3b3db1UN4FQLTyQgS7XPaLMesnTG X-Received: by 2002:a17:907:1b1f:: with SMTP id mp31mr5487321ejc.348.1613675891646; Thu, 18 Feb 2021 11:18:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613675891; cv=none; d=google.com; s=arc-20160816; b=Iy1tZwXDuRnvYnbreAJ7Kcacwszrf2CGmqUV6ZOSDjnr6q4On7yDAoGyDTBsVvzsZs 5C77nckuHdNPskr9gItLg1E9SCpfBS74741sXMwO7KkRXcjOcmr7bg11MXnNlMjcIJS1 HpVcNEKtD7+3L6Dlq5bLGcXi6uqzX6962J4e05ow3EYgL/F9qxp/lMN4vnG1P0jT6xoS G0tY5zxXbbHt5uOb+qvIdrN/d4rqYFQwY9Tj5FhSMWelRWBOx8P91WEg0FOKjrN4v+jW m5gpVx0qsibuMFfdXptki+Xji3CIrC254uZ+rHVj41biuJ4hrr1bUMu59zyiC+xmzxZ1 Luqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Tgi2PT/4+anU3pfYa8JYNys7ChKyAjV7/eCb1ADvlbQ=; b=sKtgH3x/HQMZrkuvAgzsBYbpl6zwrgy7DHLWaQWSVtrMUT1oTH3smB39eRAmkYyEy0 aS1fcdGhzj/ieMN48jnqe8fY582+Q8GXH1D2k354NHeV7/VKr1ZsT8Kki1zssQdNJ1i+ LPXilhCPYRvFH7UO3pI5oiNCcXqRTIXmSew30HnOvjGb/Uy3REpd1XKsjRRR4E/yoqdS BdNvnz2mA1X4TJ6gAU3Jblh9UYv9SE9wrgT5+7xWdEv/SLEWR23wcRIP2wt/WE3K+lgu shjhSFeObref7CzE8C3pJREkuYo/D9IQcY0VAXwBx6aU/yclr5MDS0oCC072bUDUZE2i vRpg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="qnE6/yHi"; 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 e22si4957739edu.45.2021.02.18.11.17.44; Thu, 18 Feb 2021 11:18:11 -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="qnE6/yHi"; 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 S233991AbhBRTQC (ORCPT + 99 others); Thu, 18 Feb 2021 14:16:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33664 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233640AbhBRRzw (ORCPT ); Thu, 18 Feb 2021 12:55:52 -0500 Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D9C0C061574 for ; Thu, 18 Feb 2021 09:55:12 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id d7so2655387otq.6 for ; Thu, 18 Feb 2021 09:55:12 -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=Tgi2PT/4+anU3pfYa8JYNys7ChKyAjV7/eCb1ADvlbQ=; b=qnE6/yHiDn67OdK7pvvUIINFuUG0S7jPrr6b+2c9mMjTNonTCnBWnGpIwWe1t3UQcG CpBm51EqMP4Wns59KX4czCyugG21sPLFkFMHuYE7SkXkX8NfYQmKW013EmuPJWXwqy+3 +hEyGZm/ZL+7DK+fNy9PTWj4OFleCawPLaOK+fXIwwDiIvDVbFXMx3L76C04CpnDdhZd yRh+2OFj6Xs7Foamx9ojJ+rktQ6XVgtH4xk/JQohBbaI0u7VUlxmVTKHTV1OVfS4u8ZF ChRahBKg3/KFerxqZZq+cRsFzwZjPWHc07YQ4mKX0cgPTOVOdbdhztLFuBVv1Z16Bfbx IpoA== 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=Tgi2PT/4+anU3pfYa8JYNys7ChKyAjV7/eCb1ADvlbQ=; b=N6i25l2XDMiizzBYrwqiBGMkt+Dtn6rOeLZsiLBKT4TzsikTaxcTz6+mp1gSSC9ddc Igv8o0AH8xuSDAqL+orPilyGXlVZGskkIyr+Wt1iHLNv9SDZBpy1/jmbRSrP8vkijyvB YzBXFC4WM6RnFBJm65SQTjDFkAWCZySBnJzAFj5u/j6USZxxk1utBh3JB5Z1NjM2WakA xRYH1tH1v8LmOM4wbtWwvahPbjj0f/D+NN/BbeHdasbTwtWJldk5Dk4hs+X8PymFmfjX LCLU45cgsoDd9g4vcQgX85AsEdbCqvFHZ5LTMZexXGpWrjC8GQxNBUcT06yIpC1htkn6 gYjQ== X-Gm-Message-State: AOAM533kWxzHOKTpiujjgeA2QasFUFa3ZV6zfePbevLVQusJPMDCjsts 3OFGGUXOyfpXXA6zXqa8d9+EmO4Pby/J6bk90yReFA== X-Received: by 2002:a9d:7a47:: with SMTP id z7mr3786711otm.295.1613670911413; Thu, 18 Feb 2021 09:55:11 -0800 (PST) MIME-Version: 1.0 References: <20210218100450.2157308-1-david.edmondson@oracle.com> <708f2956-fa0f-b008-d3d2-93067f95783c@redhat.com> <8f9d4ef7-ddad-160b-2d94-69f4370e8702@redhat.com> In-Reply-To: From: Jim Mattson Date: Thu, 18 Feb 2021 09:55:00 -0800 Message-ID: Subject: Re: [PATCH] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid To: Sean Christopherson Cc: Paolo Bonzini , David Edmondson , LKML , Borislav Petkov , Wanpeng Li , Thomas Gleixner , Ingo Molnar , Vitaly Kuznetsov , "the arch/x86 maintainers" , "H. Peter Anvin" , kvm list , Joerg Roedel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 18, 2021 at 8:35 AM Sean Christopherson wrote: > > 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. Shouldn't dump_vmcs() simply dump the contents of the VMCS, in its entirety? What does it matter what the value of EFER is?