[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZjBiLDJ4SdQ0p5xm@chao-email>
Date: Tue, 30 Apr 2024 11:14:52 +0800
From: Chao Gao <chao.gao@...el.com>
To: Xin Li <xin3.li@...el.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-doc@...r.kernel.org"
<linux-doc@...r.kernel.org>, "linux-kselftest@...r.kernel.org"
<linux-kselftest@...r.kernel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>, "corbet@....net"
<corbet@....net>, "tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "shuah@...nel.org"
<shuah@...nel.org>, "vkuznets@...hat.com" <vkuznets@...hat.com>,
"peterz@...radead.org" <peterz@...radead.org>, "Shankar, Ravi V"
<ravi.v.shankar@...el.com>, "xin@...or.com" <xin@...or.com>
Subject: Re: [PATCH v2 12/25] KVM: VMX: Handle FRED event data
>index ee61d2c25cb0..f622fb90a098 100644
>--- a/arch/x86/kvm/vmx/vmx.c
>+++ b/arch/x86/kvm/vmx/vmx.c
>@@ -1871,9 +1871,29 @@ 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))
>+ event_data = to_vmx(vcpu)->fred_xfd_event_data;
>+
IMO, deriving an event_data from CR2/DR6 is a little short-sighted because the
event_data and CR2/DR6 __can__ be different, e.g., L1 VMM __can__ set CR2 to A
and event_data field to B (!=A) when injecting #PF.
And this approach cannot be extended to handle a (future) exception whose
event_data isn't tied to a dedicated register like CR2/DR6.
Adding a new field fred_xfd_event_data in struct vcpu has problems too:
fred_xfd_event_data gets lost during migration; strickly speaking, event_data
is tied to an exception rather than a CPU. e.g., the CPU may detect a nested
exception when delivering one and both have their own event_data.
I think we can make event_data a property of exceptions. i.e., add a payload2
to struct kvm_queued_exception. and add new APIs to kvm_queue_exception* family
to accept a payload2 and in VMX code, just program payload2 to the VMCS
event_data field if FRED is enabled. KVM ABI should be extended as well to pass
payload2 to userspace like how the payload is handled in
kvm_vcpu_ioctl_x86_get/put_vcpu_events.
Powered by blists - more mailing lists