lkml.org 
[lkml]   [2024]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2 06/10] KVM, x86: add architectural support code for #VE
From
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@intel.com>.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

..

> 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@google.com

\
 
 \ /
  Last update: 2024-04-18 00:55    [W:0.112 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site