From: Xin Li <xin3.li@intel.com>
To: kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-kselftest@vger.kernel.org
Cc: seanjc@google.com, pbonzini@redhat.com, corbet@lwn.net,
kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, vkuznets@redhat.com, peterz@infradead.org,
ravi.v.shankar@intel.com
Subject: [PATCH v1 12/23] KVM: VMX: Handle FRED event data
Date: Wed, 8 Nov 2023 10:29:52 -0800 [thread overview]
Message-ID: <20231108183003.5981-13-xin3.li@intel.com> (raw)
In-Reply-To: <20231108183003.5981-1-xin3.li@intel.com>
Set injected-event data when injecting a #PF, #DB, or #NM caused
by extended feature disable using FRED event delivery, and save
original-event data for being used as injected-event data.
Unlike IDT using some extra CPU register as part of an event
context, e.g., %cr2 for #PF, FRED saves a complete event context
in its stack frame, e.g., FRED saves the faulting linear address
of a #PF into the event data field defined in its stack frame.
Thus a new VMX control field called injected-event data is added
to provide the event data that will be pushed into a FRED stack
frame for VM entries that inject an event using FRED event delivery.
In addition, a new VM exit information field called original-event
data is added to store the event data that would have saved into a
FRED stack frame for VM exits that occur during FRED event delivery.
After such a VM exit is handled to allow the original-event to be
delivered, the data in the original-event data VMCS field needs to
be set into the injected-event data VMCS field for the injection of
the original event.
Tested-by: Shan Kang <shan.kang@intel.com>
Signed-off-by: Xin Li <xin3.li@intel.com>
---
arch/x86/include/asm/vmx.h | 4 ++
arch/x86/kvm/vmx/vmx.c | 84 +++++++++++++++++++++++++++++++++++---
arch/x86/kvm/x86.c | 10 ++++-
3 files changed, 91 insertions(+), 7 deletions(-)
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index d54a1a1057b0..97729248e844 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -253,8 +253,12 @@ enum vmcs_field {
PID_POINTER_TABLE_HIGH = 0x00002043,
SECONDARY_VM_EXIT_CONTROLS = 0x00002044,
SECONDARY_VM_EXIT_CONTROLS_HIGH = 0x00002045,
+ INJECTED_EVENT_DATA = 0x00002052,
+ INJECTED_EVENT_DATA_HIGH = 0x00002053,
GUEST_PHYSICAL_ADDRESS = 0x00002400,
GUEST_PHYSICAL_ADDRESS_HIGH = 0x00002401,
+ ORIGINAL_EVENT_DATA = 0x00002404,
+ ORIGINAL_EVENT_DATA_HIGH = 0x00002405,
VMCS_LINK_POINTER = 0x00002800,
VMCS_LINK_POINTER_HIGH = 0x00002801,
GUEST_IA32_DEBUGCTL = 0x00002802,
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 58d01e845804..67fd4a56d031 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1880,9 +1880,30 @@ static void vmx_inject_exception(struct kvm_vcpu *vcpu)
vmcs_write32(VM_ENTRY_INSTRUCTION_LEN,
vmx->vcpu.arch.event_exit_inst_len);
intr_info |= INTR_TYPE_SOFT_EXCEPTION;
- } else
+ } else {
intr_info |= INTR_TYPE_HARD_EXCEPTION;
+ if (kvm_is_fred_enabled(vcpu)) {
+ u64 event_data = 0;
+
+ if (is_debug(intr_info))
+ /*
+ * Compared to DR6, FRED #DB event data saved on
+ * the stack frame have bits 4 ~ 11 and 16 ~ 31
+ * inverted, i.e.,
+ * fred_db_event_data = dr6 ^ 0xFFFF0FF0UL
+ */
+ event_data = vcpu->arch.dr6 ^ DR6_RESERVED;
+ else if (is_page_fault(intr_info))
+ event_data = vcpu->arch.cr2;
+ else if (is_nm_fault(intr_info) &&
+ vcpu->arch.guest_fpu.fpstate->xfd)
+ event_data = vcpu->arch.guest_fpu.xfd_err;
+
+ vmcs_write64(INJECTED_EVENT_DATA, event_data);
+ }
+ }
+
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info);
vmx_clear_hlt(vcpu);
@@ -7226,7 +7247,8 @@ static void vmx_recover_nmi_blocking(struct vcpu_vmx *vmx)
static void __vmx_complete_interrupts(struct kvm_vcpu *vcpu,
u32 idt_vectoring_info,
int instr_len_field,
- int error_code_field)
+ int error_code_field,
+ int event_data_field)
{
u8 vector;
int type;
@@ -7260,6 +7282,37 @@ static void __vmx_complete_interrupts(struct kvm_vcpu *vcpu,
vcpu->arch.event_exit_inst_len = vmcs_read32(instr_len_field);
fallthrough;
case INTR_TYPE_HARD_EXCEPTION:
+ if (kvm_is_fred_enabled(vcpu) && event_data_field) {
+ /*
+ * Save original-event data for being used as injected-event data.
+ */
+ u64 event_data = vmcs_read64(event_data_field);
+
+ switch (vector) {
+ case DB_VECTOR:
+ get_debugreg(vcpu->arch.dr6, 6);
+ WARN_ON(vcpu->arch.dr6 != (event_data ^ DR6_RESERVED));
+ vcpu->arch.dr6 = event_data ^ DR6_RESERVED;
+ break;
+ case NM_VECTOR:
+ if (vcpu->arch.guest_fpu.fpstate->xfd) {
+ rdmsrl(MSR_IA32_XFD_ERR, vcpu->arch.guest_fpu.xfd_err);
+ WARN_ON(vcpu->arch.guest_fpu.xfd_err != event_data);
+ vcpu->arch.guest_fpu.xfd_err = event_data;
+ } else {
+ WARN_ON(event_data != 0);
+ }
+ break;
+ case PF_VECTOR:
+ WARN_ON(vcpu->arch.cr2 != event_data);
+ vcpu->arch.cr2 = event_data;
+ break;
+ default:
+ WARN_ON(event_data != 0);
+ break;
+ }
+ }
+
if (idt_vectoring_info & VECTORING_INFO_DELIVER_CODE_MASK) {
u32 err = vmcs_read32(error_code_field);
kvm_requeue_exception_e(vcpu, vector, err);
@@ -7279,9 +7332,11 @@ static void __vmx_complete_interrupts(struct kvm_vcpu *vcpu,
static void vmx_complete_interrupts(struct vcpu_vmx *vmx)
{
- __vmx_complete_interrupts(&vmx->vcpu, vmx->idt_vectoring_info,
+ __vmx_complete_interrupts(&vmx->vcpu,
+ vmx->idt_vectoring_info,
VM_EXIT_INSTRUCTION_LEN,
- IDT_VECTORING_ERROR_CODE);
+ IDT_VECTORING_ERROR_CODE,
+ ORIGINAL_EVENT_DATA);
}
static void vmx_cancel_injection(struct kvm_vcpu *vcpu)
@@ -7289,7 +7344,8 @@ static void vmx_cancel_injection(struct kvm_vcpu *vcpu)
__vmx_complete_interrupts(vcpu,
vmcs_read32(VM_ENTRY_INTR_INFO_FIELD),
VM_ENTRY_INSTRUCTION_LEN,
- VM_ENTRY_EXCEPTION_ERROR_CODE);
+ VM_ENTRY_EXCEPTION_ERROR_CODE,
+ 0);
vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, 0);
}
@@ -7406,6 +7462,24 @@ static noinstr void vmx_vcpu_enter_exit(struct kvm_vcpu *vcpu,
vmx_disable_fb_clear(vmx);
+ /*
+ * %cr2 needs to be saved after a VM exit and restored before a VM
+ * entry in case a VM exit happens immediately after delivery of a
+ * guest #PF but before guest reads %cr2.
+ *
+ * A FRED guest should read its #PF faulting linear address from
+ * the event data field in its FRED stack frame instead of %cr2.
+ * But the FRED 5.0 spec still requires a FRED CPU to update %cr2
+ * in the normal way, thus %cr2 is still updated even for a FRED
+ * guest.
+ *
+ * Note, an NMI could interrupt KVM:
+ * 1) after VM exit but before CR2 is saved.
+ * 2) after CR2 is restored but before VM entry.
+ * And a #PF could happen durng NMI handlng, which overwrites %cr2.
+ * Thus exc_nmi() should save and restore %cr2 upon entering and
+ * before leaving to make sure %cr2 not corrupted.
+ */
if (vcpu->arch.cr2 != native_read_cr2())
native_write_cr2(vcpu->arch.cr2);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c5a55810647f..d190bfc63fc4 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -680,8 +680,14 @@ static void kvm_multiple_exception(struct kvm_vcpu *vcpu,
vcpu->arch.exception.injected = true;
if (WARN_ON_ONCE(has_payload)) {
/*
- * A reinjected event has already
- * delivered its payload.
+ * For a reinjected event, KVM delivers its
+ * payload through:
+ * #PF: save %cr2 into arch.cr2 immediately
+ * after VM exits.
+ * #DB: save %dr6 into arch.dr6 later in
+ * sync_dirty_debug_regs().
+ *
+ * For FRED guest, see __vmx_complete_interrupts().
*/
has_payload = false;
payload = 0;
--
2.42.0
next prev parent reply other threads:[~2023-11-08 19:00 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 18:29 [PATCH v1 00/23] Enable FRED with KVM VMX Xin Li
2023-11-08 18:29 ` [PATCH v1 01/23] KVM: VMX: Cleanup VMX basic information defines and usages Xin Li
2023-11-08 18:29 ` [PATCH v1 02/23] KVM: VMX: Cleanup VMX misc " Xin Li
2023-11-08 18:29 ` [PATCH v1 03/23] KVM: VMX: Add support for the secondary VM exit controls Xin Li
2023-11-08 18:29 ` [PATCH v1 04/23] KVM: x86: Mark CR4.FRED as not reserved Xin Li
2023-11-08 18:29 ` [PATCH v1 05/23] KVM: VMX: Initialize FRED VM entry/exit controls in vmcs_config Xin Li
2023-11-09 8:53 ` Chao Gao
2023-11-09 15:15 ` Sean Christopherson
2023-11-10 0:04 ` Li, Xin3
2023-11-10 15:01 ` Sean Christopherson
2023-11-14 4:05 ` Li, Xin3
2023-11-13 17:18 ` Nikolay Borisov
2023-11-15 2:39 ` Li, Xin3
2023-11-08 18:29 ` [PATCH v1 06/23] KVM: VMX: Defer enabling FRED MSRs save/load until after set CPUID Xin Li
2023-11-09 9:15 ` Chao Gao
2023-11-09 23:50 ` Li, Xin3
2023-11-10 0:18 ` Sean Christopherson
2023-11-14 2:50 ` Li, Xin3
2023-11-15 21:47 ` Sean Christopherson
2023-11-08 18:29 ` [PATCH v1 07/23] KVM: VMX: Disable intercepting FRED MSRs Xin Li
2023-11-09 9:21 ` Chao Gao
2023-11-08 18:29 ` [PATCH v1 08/23] KVM: VMX: Initialize VMCS FRED fields Xin Li
2023-11-13 3:04 ` Chao Gao
2023-11-14 6:02 ` Li, Xin3
2023-11-14 6:51 ` Li, Xin3
2023-11-08 18:29 ` [PATCH v1 09/23] KVM: VMX: Switch FRED RSP0 between host and guest Xin Li
2023-11-13 3:47 ` Chao Gao
2023-11-14 5:17 ` Li, Xin3
2023-11-14 7:47 ` Chao Gao
2023-11-15 3:04 ` Li, Xin3
2023-11-08 18:29 ` [PATCH v1 10/23] KVM: VMX: Add support for FRED context save/restore Xin Li
2023-11-13 5:24 ` Chao Gao
2023-11-14 4:48 ` Li, Xin3
2023-11-08 18:29 ` [PATCH v1 11/23] KVM: x86: Add kvm_is_fred_enabled() Xin Li
2023-11-13 7:35 ` Chao Gao
2023-11-14 4:42 ` Li, Xin3
2023-11-14 8:16 ` Chao Gao
2023-11-14 18:57 ` Li, Xin3
2023-11-20 9:04 ` Li, Xin3
2023-11-08 18:29 ` Xin Li [this message]
2023-11-13 10:14 ` [PATCH v1 12/23] KVM: VMX: Handle FRED event data Chao Gao
2023-11-14 4:34 ` Li, Xin3
2023-11-14 8:58 ` Chao Gao
2023-11-15 2:52 ` Li, Xin3
2023-11-16 2:39 ` Chao Gao
2023-11-20 8:16 ` Li, Xin3
2023-11-08 18:29 ` [PATCH v1 13/23] KVM: VMX: Handle VMX nested exception for FRED Xin Li
2023-11-14 7:40 ` Chao Gao
2023-11-15 3:03 ` Li, Xin3
2023-12-06 8:37 ` Li, Xin3
2023-12-07 8:42 ` Chao Gao
2023-12-07 10:09 ` Li, Xin3
2023-12-08 1:56 ` Chao Gao
2023-12-08 23:48 ` Li, Xin3
2023-11-08 18:29 ` [PATCH v1 14/23] KVM: VMX: Dump FRED context in dump_vmcs() Xin Li
2023-11-14 14:36 ` Nikolay Borisov
2023-11-15 2:41 ` Li, Xin3
2023-11-08 18:29 ` [PATCH v1 15/23] KVM: nVMX: Add support for the secondary VM exit controls Xin Li
2023-11-09 8:21 ` Jeremi Piotrowski
2023-11-10 0:12 ` Li, Xin3
2023-11-20 15:52 ` Vitaly Kuznetsov
2023-11-20 17:42 ` Li, Xin3
2023-11-08 18:29 ` [PATCH v1 16/23] KVM: nVMX: Add FRED VMCS fields Xin Li
2023-11-08 18:29 ` [PATCH v1 17/23] KVM: nVMX: Add support for VMX FRED controls Xin Li
2023-11-08 18:29 ` [PATCH v1 18/23] KVM: nVMX: Add VMCS FRED states checking Xin Li
2023-11-08 18:29 ` [PATCH v1 19/23] KVM: x86: Allow FRED/LKGS/WRMSRNS to be exposed to guests Xin Li
2023-11-08 18:30 ` [PATCH v1 20/23] KVM: selftests: Add FRED VMCS fields to evmcs Xin Li
2023-11-08 18:30 ` [PATCH v1 21/23] KVM: selftests: Run debug_regs test with FRED enabled Xin Li
2023-11-08 18:30 ` [PATCH v1 22/23] KVM: selftests: Add a new VM guest mode to run user level code Xin Li
2023-11-08 18:30 ` [PATCH v1 23/23] KVM: selftests: Add fred exception tests Xin Li
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=20231108183003.5981-13-xin3.li@intel.com \
--to=xin3.li@intel.com \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=kys@microsoft.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wei.liu@kernel.org \
--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.