Received: by 2002:a89:413:0:b0:1fd:dba5:e537 with SMTP id m19csp340566lqs; Thu, 13 Jun 2024 11:29:55 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCViAfjREpbtQB29YLGnGvzQO4NT+rGkDlQaKVOoKeuQL6dIKvIbwzZxsww0/BI89oHzqkBODwGYsiP0aDX6DxZiEJzjkGsEl60cDcAYeA== X-Google-Smtp-Source: AGHT+IHO6ChtG+Nq/axmK2z7k7t1EL+PNy0NlLK/i0rFoZ/u8lp69bGxOgdY0wh7fUmKbfdiup34 X-Received: by 2002:ad4:590c:0:b0:6b0:4542:e42e with SMTP id 6a1803df08f44-6b2afcc0ebfmr3644306d6.28.1718303395468; Thu, 13 Jun 2024 11:29:55 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1718303395; cv=pass; d=google.com; s=arc-20160816; b=sga2VTtguflxR5wDYxQCjgQLGxg/tIGM12+iO3tnPE5P9VsULLJ/lMVdD6mW4mXDFR fWYe3aOSSrFk2yiXRwWOeSsPAkimA2UAjQsDkV8mAnhhRHtwS54aSO5e6EGO/GVwt+u/ mG0NN+Sbsw5ETQpnPZ9mYan2VVhZqz+O1s3YMpLSzZ3fiDg93g1qYHf+5mu5EIy4hC11 jjy7eNLHf5q4BBKXN+N8ANXlVQnDrrH9AevJoPssJC2c6eEM5gOVN0R/njAxump0UZPx ocils8iZIZ1Idjxj/CxY9fiJNOiZZ8zUmyMFBzf9fWR31dEWy9Jzll7D3GR/R6BGpBZs OmXQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:from:subject:message-id:references:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:in-reply-to:date :dkim-signature; bh=xow6eF8EcU1B/jVaJ9RrJxjk/wXRNzAI1C7xG3uJG5s=; fh=uzCrZMsEnMDs/MfHVUnv96LpYzP7XoyfHkNMvKnZn4s=; b=x6bwd/NxmZFLqvKCrCMZ/d0XwacqJ2zrRKY16PTIeehcTS33PBKIarCZwItb10tzK1 fjg/bl0mWK1o8BjDUY1hkgNdSZWmmZ7EwCpU97+g65ctgs8zp1BJrHFC8GzZjMh27+Dl eDr2GKrvqQ2uqNsHdxazZFDrQcp7+NFwZaTZflWWp1EVIYp1o83PJlYMvCNL9z8K0x66 OO7FsY86OybRUoOOJ4/NypthIHJvEWh3rSsX0fcOs7DZKpN9xV9oeumquoR1Jwl15DAX 5oSUqBZww8W7dwP3WP/ug+IMlQkYi0DgTPDnKn0gVY89Vvos7tx+NnLTp8bgxnIiLB5c WbnQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b="BT3/a0o8"; arc=pass (i=1 spf=pass spfdomain=flex--seanjc.bounces.google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-213827-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-213827-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id 6a1803df08f44-6b2a5a16e68si20812486d6.22.2024.06.13.11.29.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Jun 2024 11:29:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-213827-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b="BT3/a0o8"; arc=pass (i=1 spf=pass spfdomain=flex--seanjc.bounces.google.com dkim=pass dkdomain=google.com dmarc=pass fromdomain=google.com); spf=pass (google.com: domain of linux-kernel+bounces-213827-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-213827-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 1FE591C21D97 for ; Thu, 13 Jun 2024 18:29:55 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3B5AE14B946; Thu, 13 Jun 2024 18:29:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="BT3/a0o8" Received: from mail-yb1-f201.google.com (mail-yb1-f201.google.com [209.85.219.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2123D14AD1E for ; Thu, 13 Jun 2024 18:29:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718303379; cv=none; b=IBUaH0KTUPHxvMhQdH/fmt1ITMjmuLuuiWYH7Tpw2wvZlxPodEfzrDs6jCdwpknNWlKT0cNwXLKHap72CPS/7SF+sZ648YMFoMfjjubMo4/w7QeYuScvf4cHocG/Z8tXpHyUit7VJFVTpusEs03NSuPdv3CnrTVv3ZEoKDgJpmM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718303379; c=relaxed/simple; bh=GZUo36Np0gui5iMC3kWaWJvqb8+ie9cBFLRdcmIQb2A=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=O8bBeRH9zaK610JcjqRFZsMZzNoRKWLat//pEN1/cwCo0rXDZrO/KJV+yWUR2RAoCZi4CrglI06UMaOiUKJ6UJVmwnOkCfgKmUT8EGd61Ym6TrzibIBcSCTWUsBnoMUNCqSEUJ8sz90ZDLcQ2ddi6bvQNHjLzSvPnvtRylY2fE4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=BT3/a0o8; arc=none smtp.client-ip=209.85.219.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Received: by mail-yb1-f201.google.com with SMTP id 3f1490d57ef6-dff151b19f0so199945276.2 for ; Thu, 13 Jun 2024 11:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1718303376; x=1718908176; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=xow6eF8EcU1B/jVaJ9RrJxjk/wXRNzAI1C7xG3uJG5s=; b=BT3/a0o8kiFR3KS6Jw+JNm1v4tsfs31+bLWpuKqiuvTodoNvmFwEQdlRLj+92K7je4 okcIuYGwxsSjSsNhJjHSEypbJR8wbZymYZg3iI4kIx2kh1/PuNmdkwJoewkh9Vqk0ksE lWTAe/S1dBPD6rz92JTN/zJpFso2bEYdGIKQUztFMmK22dLvV25CmWEaNHIcEae4DuK/ rr+kwhvxBpnvnGXt4l42J3CGe1qc+vHPClhcQcEYVW26EcBoVsmiH6bt6l2YxIydgZeQ 0GHrDoYqRNYzTlY/czTNV0H4aSM4MvAO4aJW5liIdSRhI/UkXmXr3AOBsOoPi4uTAbzv LkdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718303376; x=1718908176; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xow6eF8EcU1B/jVaJ9RrJxjk/wXRNzAI1C7xG3uJG5s=; b=MhdOK//rA6r08GS1f9CVeso6i8D8yhLOGV22DNh3A9346Sr3yoMoBKailJv9Flb60C l52Bw+CJX3zz4GvvsJjQKQfpst0tbIdmL4iRNEa6eXBZvDShH9r6k1cRZUmKBXFKnhiA i10kXR6iCLXVVEmgW5/lv4X+sgQxiUahD56AUVQBm3HayW6bMgkcctwd8LJfwE+8SrHz d1tZGHlSWqnot+HLaFCQ9rzBxZGeOLvwePuWtKcirkf6lzkLl4W/4eyCN7h1Cxn19NkM 281ZP+EFKWa40UX1eqLy+dmhxlQKtqp8ZmJuqsS4vGZDlon2mmyCEUtpK9gHGQSYzV5u 7XrA== X-Gm-Message-State: AOJu0Yz42bVPple4/comBdwWP9CSujD7MIOzyLDWVfAatQZEjIe/lPVN z5kOsAe5aVepPVsTkotmoDT0LwmvsPQYnhIVeyT4Y+glFwjrhCyFT7ErcmBrOfw25QesL0mW/46 kjg== X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:e89:b0:dff:9dc:7e41 with SMTP id 3f1490d57ef6-dff154ac5fcmr12681276.11.1718303376176; Thu, 13 Jun 2024 11:29:36 -0700 (PDT) Date: Thu, 13 Jun 2024 11:29:34 -0700 In-Reply-To: <20240207172646.3981-20-xin3.li@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20240207172646.3981-1-xin3.li@intel.com> <20240207172646.3981-20-xin3.li@intel.com> Message-ID: Subject: Re: [PATCH v2 19/25] KVM: nVMX: Add FRED VMCS fields From: Sean Christopherson To: Xin Li Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, pbonzini@redhat.com, corbet@lwn.net, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, shuah@kernel.org, vkuznets@redhat.com, peterz@infradead.org, ravi.v.shankar@intel.com, xin@zytor.com Content-Type: text/plain; charset="us-ascii" On Wed, Feb 07, 2024, Xin Li wrote: > Add FRED VMCS fields to nested VMX context management. > > Todo: change VMCS12_REVISION, as struct vmcs12 is changed. It actually doesn't, the comment is just stale. At this point, KVM must _never_ change VMCS12_REVISION as doing so will break backwards compatibility. I'll post this once I've written a changelog: --- arch/x86/kvm/vmx/vmcs12.h | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/vmx/vmcs12.h b/arch/x86/kvm/vmx/vmcs12.h index edf7fcef8ccf..d67bebb9f1c2 100644 --- a/arch/x86/kvm/vmx/vmcs12.h +++ b/arch/x86/kvm/vmx/vmcs12.h @@ -207,11 +207,9 @@ struct __packed vmcs12 { }; /* - * VMCS12_REVISION is an arbitrary id that should be changed if the content or - * layout of struct vmcs12 is changed. MSR_IA32_VMX_BASIC returns this id, and - * VMPTRLD verifies that the VMCS region that L1 is loading contains this id. + * VMCS12_REVISION is KVM's arbitrary id for the layout of struct vmcs12. * - * IMPORTANT: Changing this value will break save/restore compatibility with + * DO NOT change this value, as it will break save/restore compatibility with * older kvm releases. */ #define VMCS12_REVISION 0x11e57ed0 @@ -225,7 +223,8 @@ struct __packed vmcs12 { #define VMCS12_SIZE KVM_STATE_NESTED_VMX_VMCS_SIZE /* - * For save/restore compatibility, the vmcs12 field offsets must not change. + * For save/restore compatibility, the vmcs12 field offsets must not change, + * although appending fields and/or filling gaps is obviously allowed. */ #define CHECK_OFFSET(field, loc) \ ASSERT_STRUCT_OFFSET(struct vmcs12, field, loc) base-commit: 878fe4c2f7eead383f2b306cbafd300006dd518c -- > Signed-off-by: Xin Li > Tested-by: Shan Kang > --- > > Change since v1: > * Remove hyperv TLFS related changes (Jeremi Piotrowski). > * Use kvm_cpu_cap_has() instead of cpu_feature_enabled() (Chao Gao). > --- > Documentation/virt/kvm/x86/nested-vmx.rst | 18 +++++ > arch/x86/kvm/vmx/nested.c | 91 +++++++++++++++++++---- > arch/x86/kvm/vmx/vmcs12.c | 18 +++++ > arch/x86/kvm/vmx/vmcs12.h | 36 +++++++++ > arch/x86/kvm/vmx/vmcs_shadow_fields.h | 4 + > 5 files changed, 152 insertions(+), 15 deletions(-) > > diff --git a/Documentation/virt/kvm/x86/nested-vmx.rst b/Documentation/virt/kvm/x86/nested-vmx.rst > index e64ef231f310..87fa9f3877ab 100644 > --- a/Documentation/virt/kvm/x86/nested-vmx.rst > +++ b/Documentation/virt/kvm/x86/nested-vmx.rst > @@ -218,6 +218,24 @@ struct shadow_vmcs is ever changed. > u16 host_gs_selector; > u16 host_tr_selector; > u64 secondary_vm_exit_controls; > + u64 guest_ia32_fred_config; > + u64 guest_ia32_fred_rsp1; > + u64 guest_ia32_fred_rsp2; > + u64 guest_ia32_fred_rsp3; > + u64 guest_ia32_fred_stklvls; > + u64 guest_ia32_fred_ssp1; > + u64 guest_ia32_fred_ssp2; > + u64 guest_ia32_fred_ssp3; > + u64 host_ia32_fred_config; > + u64 host_ia32_fred_rsp1; > + u64 host_ia32_fred_rsp2; > + u64 host_ia32_fred_rsp3; > + u64 host_ia32_fred_stklvls; > + u64 host_ia32_fred_ssp1; > + u64 host_ia32_fred_ssp2; > + u64 host_ia32_fred_ssp3; > + u64 injected_event_data; > + u64 original_event_data; > }; > > > diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c > index 94da6a0a2f81..f9c1fbeac302 100644 > --- a/arch/x86/kvm/vmx/nested.c > +++ b/arch/x86/kvm/vmx/nested.c > @@ -686,6 +686,9 @@ static inline bool nested_vmx_prepare_msr_bitmap(struct kvm_vcpu *vcpu, > > nested_vmx_set_intercept_for_msr(vmx, msr_bitmap_l1, msr_bitmap_l0, > MSR_KERNEL_GS_BASE, MSR_TYPE_RW); > + > + nested_vmx_set_intercept_for_msr(vmx, msr_bitmap_l1, msr_bitmap_l0, > + MSR_IA32_FRED_RSP0, MSR_TYPE_RW); > #endif > nested_vmx_set_intercept_for_msr(vmx, msr_bitmap_l1, msr_bitmap_l0, > MSR_IA32_SPEC_CTRL, MSR_TYPE_RW); > @@ -2498,6 +2501,8 @@ static void prepare_vmcs02_early(struct vcpu_vmx *vmx, struct loaded_vmcs *vmcs0 > vmcs12->vm_entry_instruction_len); > vmcs_write32(GUEST_INTERRUPTIBILITY_INFO, > vmcs12->guest_interruptibility_info); > + if (kvm_cpu_cap_has(X86_FEATURE_FRED)) This is wrong, vmcs02 should be set from vmcs12 if and only if the field is enabled in L1's VMX configuration, i.e. iff nested_cpu_has(vmcs12, ???). Note, the ??? should be tied to whatever VMX MSR feature flag enumerates INJECTED_EVENT_DATA. KVM's clearing of X86_FEATURE_FRED when one or more pieces is missing is a software decision, i.e. not archictectural. > + vmcs_write64(INJECTED_EVENT_DATA, vmcs12->injected_event_data); > vmx->loaded_vmcs->nmi_known_unmasked = > !(vmcs12->guest_interruptibility_info & GUEST_INTR_STATE_NMI); > } else { > @@ -2548,6 +2553,17 @@ static void prepare_vmcs02_rare(struct vcpu_vmx *vmx, struct vmcs12 *vmcs12) > vmcs_writel(GUEST_GDTR_BASE, vmcs12->guest_gdtr_base); > vmcs_writel(GUEST_IDTR_BASE, vmcs12->guest_idtr_base); > > + if (kvm_cpu_cap_has(X86_FEATURE_FRED)) { Same thing here. > + vmcs_write64(GUEST_IA32_FRED_CONFIG, vmcs12->guest_ia32_fred_config); > + vmcs_write64(GUEST_IA32_FRED_RSP1, vmcs12->guest_ia32_fred_rsp1); > + vmcs_write64(GUEST_IA32_FRED_RSP2, vmcs12->guest_ia32_fred_rsp2); > + vmcs_write64(GUEST_IA32_FRED_RSP3, vmcs12->guest_ia32_fred_rsp3); > + vmcs_write64(GUEST_IA32_FRED_STKLVLS, vmcs12->guest_ia32_fred_stklvls); > + vmcs_write64(GUEST_IA32_FRED_SSP1, vmcs12->guest_ia32_fred_ssp1); > + vmcs_write64(GUEST_IA32_FRED_SSP2, vmcs12->guest_ia32_fred_ssp2); > + vmcs_write64(GUEST_IA32_FRED_SSP3, vmcs12->guest_ia32_fred_ssp3); > + } > + > vmx->segment_cache.bitmask = 0; > } > > @@ -3835,6 +3851,22 @@ vmcs12_guest_cr4(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12) > vcpu->arch.cr4_guest_owned_bits)); > } > > +static inline unsigned long > +nested_vmx_get_event_data(struct kvm_vcpu *vcpu, bool for_ex_vmexit) Heh, two form letters for the price of one: #1 Do not use "inline" for functions that are visible only to the local compilation unit. "inline" is just a hint, and modern compilers are smart enough to inline functions when appropriate without a hint. A longer explanation/rant here: https://lore.kernel.org/all/ZAdfX+S323JVWNZC@google.com #2 Do not wrap before the function name. Linus has a nice explanation/rant on this[*]. [*] https://lore.kernel.org/all/CAHk-=wjoLAYG446ZNHfg=GhjSY6nFmuB_wA8fYd5iLBNXjo9Bw@mail.gmail.com > +{ > + struct kvm_queued_exception *ex = for_ex_vmexit ? > + &vcpu->arch.exception_vmexit : &vcpu->arch.exception; > + > + if (ex->has_payload) > + return ex->payload; > + else if (ex->vector == PF_VECTOR) > + return vcpu->arch.cr2; > + else if (ex->vector == DB_VECTOR) > + return (vcpu->arch.dr6 & ~DR6_BT) ^ DR6_ACTIVE_LOW; > + else > + return 0; I'll circle back to this on the next version, i.e. after it's reworked to account for the suggested payload changes. I highly doubt it's correct as-is. > static void vmcs12_save_pending_event(struct kvm_vcpu *vcpu, > struct vmcs12 *vmcs12, > u32 vm_exit_reason, u32 exit_intr_info) > @@ -3842,6 +3874,8 @@ static void vmcs12_save_pending_event(struct kvm_vcpu *vcpu, > u32 idt_vectoring; > unsigned int nr; > > + vmcs12->original_event_data = 0; > + > /* > * Per the SDM, VM-Exits due to double and triple faults are never > * considered to occur during event delivery, even if the double/triple > @@ -3880,6 +3914,12 @@ static void vmcs12_save_pending_event(struct kvm_vcpu *vcpu, > vcpu->arch.exception.error_code; > } > > + idt_vectoring |= vcpu->arch.exception.nested ? > + INTR_INFO_NESTED_EXCEPTION_MASK : 0; Please stop using ternary operators this way. It's less readable and the same number of lines as: if (vcpu->arch.exception.nested) idt_vectoring |= INTR_INFO_NESTED_EXCEPTION_MASK; > + > + vmcs12->original_event_data = > + nested_vmx_get_event_data(vcpu, false); > + > vmcs12->idt_vectoring_info_field = idt_vectoring; > } else if (vcpu->arch.nmi_injected) { > vmcs12->idt_vectoring_info_field = > @@ -3970,19 +4010,7 @@ static void nested_vmx_inject_exception_vmexit(struct kvm_vcpu *vcpu) > struct kvm_queued_exception *ex = &vcpu->arch.exception_vmexit; > u32 intr_info = ex->vector | INTR_INFO_VALID_MASK; > struct vmcs12 *vmcs12 = get_vmcs12(vcpu); > - unsigned long exit_qual; > - > - if (ex->has_payload) { > - exit_qual = ex->payload; > - } else if (ex->vector == PF_VECTOR) { > - exit_qual = vcpu->arch.cr2; > - } else if (ex->vector == DB_VECTOR) { > - exit_qual = vcpu->arch.dr6; > - exit_qual &= ~DR6_BT; > - exit_qual ^= DR6_ACTIVE_LOW; > - } else { > - exit_qual = 0; > - } > + unsigned long exit_qual = nested_vmx_get_event_data(vcpu, true); This can't possibly be correct, EXIT_QUAL and EVENT_DATA aren't equivalent, e.g. the former doesn't have XFD_ERR, but the latter does. > /* > * Unlike AMD's Paged Real Mode, which reports an error code on #PF > @@ -4003,10 +4031,12 @@ static void nested_vmx_inject_exception_vmexit(struct kvm_vcpu *vcpu) > intr_info |= INTR_INFO_DELIVER_CODE_MASK; > } > > - if (kvm_exception_is_soft(ex->vector)) > + if (kvm_exception_is_soft(ex->vector)) { > intr_info |= INTR_TYPE_SOFT_EXCEPTION; > - else > + } else { > intr_info |= INTR_TYPE_HARD_EXCEPTION; > + intr_info |= ex->nested ? INTR_INFO_NESTED_EXCEPTION_MASK : 0; Again, if (ex->nested) intr_info |= INTR_INFO_NESTED_EXCEPTION_MASK; > + if (kvm_cpu_cap_has(X86_FEATURE_FRED)) { And here > + vmcs12->guest_ia32_fred_config = vmcs_read64(GUEST_IA32_FRED_CONFIG); > + vmcs12->guest_ia32_fred_rsp1 = vmcs_read64(GUEST_IA32_FRED_RSP1); > + vmcs12->guest_ia32_fred_rsp2 = vmcs_read64(GUEST_IA32_FRED_RSP2); > + vmcs12->guest_ia32_fred_rsp3 = vmcs_read64(GUEST_IA32_FRED_RSP3); > + vmcs12->guest_ia32_fred_stklvls = vmcs_read64(GUEST_IA32_FRED_STKLVLS); > + vmcs12->guest_ia32_fred_ssp1 = vmcs_read64(GUEST_IA32_FRED_SSP1); > + vmcs12->guest_ia32_fred_ssp2 = vmcs_read64(GUEST_IA32_FRED_SSP2); > + vmcs12->guest_ia32_fred_ssp3 = vmcs_read64(GUEST_IA32_FRED_SSP3); > + } > + > vmcs12->guest_pending_dbg_exceptions = > vmcs_readl(GUEST_PENDING_DBG_EXCEPTIONS); > > @@ -4625,6 +4675,17 @@ static void load_vmcs12_host_state(struct kvm_vcpu *vcpu, > vmcs_write32(GUEST_IDTR_LIMIT, 0xFFFF); > vmcs_write32(GUEST_GDTR_LIMIT, 0xFFFF); > > + if (kvm_cpu_cap_has(X86_FEATURE_FRED)) { And here