All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Edmondson <dme@dme.org>
To: Paolo Bonzini <pbonzini@redhat.com>, linux-kernel@vger.kernel.org
Cc: Borislav Petkov <bp@alien8.de>,
	Wanpeng Li <wanpengli@tencent.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Sean Christopherson <seanjc@google.com>,
	kvm@vger.kernel.org, Jim Mattson <jmattson@google.com>,
	Joerg Roedel <joro@8bytes.org>
Subject: Re: [PATCH] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid
Date: Thu, 18 Feb 2021 13:17:46 +0000	[thread overview]
Message-ID: <cunr1ldikg5.fsf@dme.org> (raw)
In-Reply-To: <8f9d4ef7-ddad-160b-2d94-69f4370e8702@redhat.com>

On Thursday, 2021-02-18 at 14:01:40 +01, 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.

Okay, I'll do that and come back. Thanks!

> Thanks,
>
> Paolo
>
>
>>> Paolo
>>>
>>>> Fixes: 4eb64dce8d0a ("KVM: x86: dump VMCS on invalid entry")
>>>> Signed-off-by: David Edmondson <david.edmondson@oracle.com>
>>>> ---
>>>>    arch/x86/kvm/vmx/vmx.c | 14 +++++++++-----
>>>>    arch/x86/kvm/vmx/vmx.h |  2 +-
>>>>    2 files changed, 10 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
>>>> index eb69fef57485..74ea4fe6f35e 100644
>>>> --- a/arch/x86/kvm/vmx/vmx.c
>>>> +++ b/arch/x86/kvm/vmx/vmx.c
>>>> @@ -5754,7 +5754,7 @@ static void vmx_dump_dtsel(char *name, uint32_t limit)
>>>>    	       vmcs_readl(limit + GUEST_GDTR_BASE - GUEST_GDTR_LIMIT));
>>>>    }
>>>>    
>>>> -void dump_vmcs(void)
>>>> +void dump_vmcs(struct kvm_vcpu *vcpu)
>>>>    {
>>>>    	u32 vmentry_ctl, vmexit_ctl;
>>>>    	u32 cpu_based_exec_ctrl, pin_based_exec_ctrl, secondary_exec_control;
>>>> @@ -5771,7 +5771,11 @@ 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);
>>>> +	if ((vmexit_ctl & VM_EXIT_SAVE_IA32_EFER) ||
>>>> +	    (vmentry_ctl & VM_ENTRY_LOAD_IA32_EFER))
>>>> +		efer = vmcs_read64(GUEST_IA32_EFER);
>>>> +	else
>>>> +		efer = vcpu->arch.efer;
>>>>    	secondary_exec_control = 0;
>>>>    	if (cpu_has_secondary_exec_ctrls())
>>>>    		secondary_exec_control = vmcs_read32(SECONDARY_VM_EXEC_CONTROL);
>>>> @@ -5955,7 +5959,7 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
>>>>    	}
>>>>    
>>>>    	if (exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) {
>>>> -		dump_vmcs();
>>>> +		dump_vmcs(vcpu);
>>>>    		vcpu->run->exit_reason = KVM_EXIT_FAIL_ENTRY;
>>>>    		vcpu->run->fail_entry.hardware_entry_failure_reason
>>>>    			= exit_reason;
>>>> @@ -5964,7 +5968,7 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
>>>>    	}
>>>>    
>>>>    	if (unlikely(vmx->fail)) {
>>>> -		dump_vmcs();
>>>> +		dump_vmcs(vcpu);
>>>>    		vcpu->run->exit_reason = KVM_EXIT_FAIL_ENTRY;
>>>>    		vcpu->run->fail_entry.hardware_entry_failure_reason
>>>>    			= vmcs_read32(VM_INSTRUCTION_ERROR);
>>>> @@ -6049,7 +6053,7 @@ static int vmx_handle_exit(struct kvm_vcpu *vcpu, fastpath_t exit_fastpath)
>>>>    
>>>>    unexpected_vmexit:
>>>>    	vcpu_unimpl(vcpu, "vmx: unexpected exit reason 0x%x\n", exit_reason);
>>>> -	dump_vmcs();
>>>> +	dump_vmcs(vcpu);
>>>>    	vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
>>>>    	vcpu->run->internal.suberror =
>>>>    			KVM_INTERNAL_ERROR_UNEXPECTED_EXIT_REASON;
>>>> diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
>>>> index 9d3a557949ac..f8a0ce74798e 100644
>>>> --- a/arch/x86/kvm/vmx/vmx.h
>>>> +++ b/arch/x86/kvm/vmx/vmx.h
>>>> @@ -489,6 +489,6 @@ static inline bool vmx_guest_state_valid(struct kvm_vcpu *vcpu)
>>>>    	return is_unrestricted_guest(vcpu) || __vmx_guest_state_valid(vcpu);
>>>>    }
>>>>    
>>>> -void dump_vmcs(void);
>>>> +void dump_vmcs(struct kvm_vcpu *vcpu);
>>>>    
>>>>    #endif /* __KVM_X86_VMX_H */
>>>>
>> 
>> dme.
>> 

dme.
-- 
But he said, leave me alone, I'm a family man.

  reply	other threads:[~2021-02-18 16:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-18 10:04 [PATCH] KVM: x86: dump_vmcs should not assume GUEST_IA32_EFER is valid David Edmondson
2021-02-18 11:54 ` Paolo Bonzini
2021-02-18 12:56   ` David Edmondson
2021-02-18 13:01     ` Paolo Bonzini
2021-02-18 13:17       ` David Edmondson [this message]
2021-02-18 16:35       ` Sean Christopherson
2021-02-18 17:55         ` Jim Mattson
2021-02-18 18:04           ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cunr1ldikg5.fsf@dme.org \
    --to=dme@dme.org \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.