Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp7488697pxb; Thu, 18 Feb 2021 11:21:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJxQ0Cv97MLDONpHDFapxjvAWyoCf1ghly+1Xj6wXXrO2aGkryK7QOJN3a5cZ36Hn/KGgFd1 X-Received: by 2002:a17:906:1796:: with SMTP id t22mr5474360eje.372.1613676099239; Thu, 18 Feb 2021 11:21:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613676099; cv=none; d=google.com; s=arc-20160816; b=XVfp5x7PhORw0o9bFuay/xvigiX1lM8I5wvF9dN/7+W6uLzGuoobMtCtWCBWGpJcXS B12waLkb5G/6E5BsOHFF5lSRPzaNejp55IhXRFMRo+9Mst/CdCvQ7GDbBOY4XbIkBhw8 awl9OuKLfWobGnSgHEt7rgwENXHM2bmYhsOmztjdrTiYFBPuBVK9xicoxdyhmTWhMcK+ ccANLXoIR1qzjF6fSxtTeC3j773ezcIGzPWlkb21Ec5R8oCTyxmU3ZlUL1PaFogeByAW Fz3xcHQ0oZO3wIV6zTWcF1qywIgiT52Y2ObfGmlq+bjc2uRLQ5rYmQyqLoO5jWrYMEbA EzTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=F/NjJm1o0S+ptTSdUddueRD/FVZWiax6r93BjVuqS/A=; b=XdYlmGBKokZlXpO0mYA67AqSSQFLm6aYHfUAu+abTZCbhUhXrMJ+nlIMVEfIHYGtje S9Hf9DOW70MyL7ncgHf2NMqG8G6ByztnnlZ4cWtS7ztbN5qjHcvNpLSda3jqKR+pZz4P 8JqFEQF5i5eWhRzUBJZCqN7YaMR8PP3dU0RCsVnAFL+o0t7bI9h/OLSGEXHHDb3t52sI 11+rO4iVZFdf1mo3BySc3zqpza97WRTc1bIIlY5103zi/BRTcMGnXmVrIRFOFN6oVG0e aKATDpgm4WlMp5iRip8hvkMICrkK2J74HMoAa7wb2KbQZSTk9elDAi1vOHzIndOCION6 25jA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=KpYsrfrB; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id oz27si1528525ejb.458.2021.02.18.11.21.15; Thu, 18 Feb 2021 11:21:39 -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=@redhat.com header.s=mimecast20190719 header.b=KpYsrfrB; 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=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234215AbhBRTUe (ORCPT + 99 others); Thu, 18 Feb 2021 14:20:34 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:50228 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231566AbhBRSFv (ORCPT ); Thu, 18 Feb 2021 13:05:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613671464; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=F/NjJm1o0S+ptTSdUddueRD/FVZWiax6r93BjVuqS/A=; b=KpYsrfrBmJ73BqoAod9sCNquiwTBPNvlPa1xvWsE3BRswZvWl7jofivAwqV49XjjM7xk7p PpGWPlXXyxzXEMF2O8K2Ay0mppJpyWr1KI8bZtOeC2J+uJ4AQAjHm4rApNqTJDdM81/uao ioNzD+Uv198nhd94d6uJ3K01/l0dxd4= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-26-2Kj9ijxhO1GxKPLOUhFGAA-1; Thu, 18 Feb 2021 13:04:07 -0500 X-MC-Unique: 2Kj9ijxhO1GxKPLOUhFGAA-1 Received: by mail-wm1-f70.google.com with SMTP id q24so1545683wmc.1 for ; Thu, 18 Feb 2021 10:04:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=F/NjJm1o0S+ptTSdUddueRD/FVZWiax6r93BjVuqS/A=; b=H+6zsvl/rJ3TD0D303rUJcnN5lB6bkgrHQ7SMw4goUUwgdzKJXs7MWMaROZHuUeSdx +GEGASvFaLjuku9Mk5AlLIONjOY3XL/7tg/Qxm60mg7/OCnFOKU2bLHdmf8yOfj0Txi/ dCe1O1xeUmPexEq/KcnOMRjhZaXo/YP6QN8SS7mpOjIhRnUH7RjriWEO9lHE9B0EhNTK yPB5c3TEAfeb4AmVt5aP2RjvBPag6ZmALgvXT4m/K5aRdlDSGD8pPXABvglxxsHJm90N 8cTHDuz9xZxqWmkMU3U1gkTd1d3bvObS6yrfJ+AhuCFQdSlFcfiQh+TRUTLmQfzRTGLR QCYg== X-Gm-Message-State: AOAM530TreUhvBaeXvWA3mqxzuOvuBPIQjB8PSJkQahg7N3KRWPN6E4q 4OeyqWi4Bng6haCcF/pj/0kRSfX5zBZf1atveSwUB6BPBWt9NAFRX+hPUp/Qgx+5ms0jvPbetUz XoAX3Gg4v0v4DRjuGfoPoX24R X-Received: by 2002:a05:600c:41d6:: with SMTP id t22mr4722948wmh.74.1613671446414; Thu, 18 Feb 2021 10:04:06 -0800 (PST) X-Received: by 2002:a05:600c:41d6:: with SMTP id t22mr4722910wmh.74.1613671446175; Thu, 18 Feb 2021 10:04:06 -0800 (PST) Received: from ?IPv6:2001:b07:6468:f312:c8dd:75d4:99ab:290a? ([2001:b07:6468:f312:c8dd:75d4:99ab:290a]) by smtp.gmail.com with ESMTPSA id b2sm10537937wrn.2.2021.02.18.10.04.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Feb 2021 10:04:05 -0800 (PST) Subject: Re: [PATCH] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid To: Jim Mattson , Sean Christopherson Cc: David Edmondson , LKML , Borislav Petkov , Wanpeng Li , Thomas Gleixner , Ingo Molnar , Vitaly Kuznetsov , the arch/x86 maintainers , "H. Peter Anvin" , kvm list , Joerg Roedel References: <20210218100450.2157308-1-david.edmondson@oracle.com> <708f2956-fa0f-b008-d3d2-93067f95783c@redhat.com> <8f9d4ef7-ddad-160b-2d94-69f4370e8702@redhat.com> From: Paolo Bonzini Message-ID: <13461f99-09a3-6e9a-d015-2658a46b628a@redhat.com> Date: Thu, 18 Feb 2021 19:04:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 18/02/21 18:55, Jim Mattson wrote: >>> 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? Currently it has some conditionals, but it wouldn't be a problem indeed to remove them. The MSR load list is missing state that dump_vmcs should print though. Paolo