Re: [PATCH v2 06/10] KVM, x86: add architectural support code for #VE

[Sean Christopherson]

KVM: x86:

On Tue, Apr 16, 2024, Paolo Bonzini wrote:
> Dump the contents of the #VE info data structure and assert that #VE does
> not happen, but do not yet do anything with it.
> 
> No functional change intended, separated for clarity only.
> 
> Extracted from a patch by Isaku Yamahata <isaku.yamahata@xxxxxxxxx>.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>

..

> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 6780313914f8..2c746318c6c3 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -6408,6 +6408,18 @@ void dump_vmcs(struct kvm_vcpu *vcpu)
>  	if (secondary_exec_control & SECONDARY_EXEC_ENABLE_VPID)
>  		pr_err("Virtual processor ID = 0x%04x\n",
>  		       vmcs_read16(VIRTUAL_PROCESSOR_ID));
> +	if (secondary_exec_control & SECONDARY_EXEC_EPT_VIOLATION_VE) {
> +		struct vmx_ve_information *ve_info;
> +
> +		pr_err("VE info address = 0x%016llx\n",
> +		       vmcs_read64(VE_INFORMATION_ADDRESS));
> +		ve_info = __va(vmcs_read64(VE_INFORMATION_ADDRESS));

As I pointed out in v1[*], pulling the PA->VA from the VMCS is a bad idea.  Just
use vmx->ve_info.

 : If KVM is dumping the VMCS, then something has gone wrong, possible in
 : hardware or ucode. Derefencing an address from the VMCS, which could very
 : well be corrupted, is a terrible idea.  This could easily escalate from a
 : dead VM into a dead host. 

[*] https://lore.kernel.org/all/Zd6Sy_PujXJVji0n@xxxxxxxxxx