[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <13461f99-09a3-6e9a-d015-2658a46b628a@redhat.com>
Date: Thu, 18 Feb 2021 19:04:03 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Jim Mattson <jmattson@...gle.com>,
Sean Christopherson <seanjc@...gle.com>
Cc: David Edmondson <dme@....org>, LKML <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...en8.de>,
Wanpeng Li <wanpengli@...cent.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
the arch/x86 maintainers <x86@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>, kvm list <kvm@...r.kernel.org>,
Joerg Roedel <joro@...tes.org>
Subject: Re: [PATCH] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is
valid
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
Powered by blists - more mailing lists