From: Yan Zhao <yan.y.zhao@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Rick P Edgecombe <rick.p.edgecombe@intel.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
Yuan Yao <yuan.yao@intel.com>, Kai Huang <kai.huang@intel.com>,
"isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"dmatlack@google.com" <dmatlack@google.com>,
"nik.borisov@suse.com" <nik.borisov@suse.com>
Subject: Re: [PATCH 09/21] KVM: TDX: Retry seamcall when TDX_OPERAND_BUSY with operand SEPT
Date: Sat, 14 Sep 2024 17:27:32 +0800 [thread overview]
Message-ID: <ZuVXBDCWS615bsVa@yzhao56-desk.sh.intel.com> (raw)
In-Reply-To: <ZuR09EqzU1WbQYGd@google.com>
On Fri, Sep 13, 2024 at 10:23:00AM -0700, Sean Christopherson wrote:
> On Fri, Sep 13, 2024, Yan Zhao wrote:
> > This is a lock status report of TDX module for current SEAMCALL retry issue
> > based on code in TDX module public repo https://github.com/intel/tdx-module.git
> > branch TDX_1.5.05.
> >
> > TL;DR:
> > - tdh_mem_track() can contend with tdh_vp_enter().
> > - tdh_vp_enter() contends with tdh_mem*() when 0-stepping is suspected.
>
> The zero-step logic seems to be the most problematic. E.g. if KVM is trying to
> install a page on behalf of two vCPUs, and KVM resumes the guest if it encounters
> a FROZEN_SPTE when building the non-leaf SPTEs, then one of the vCPUs could
> trigger the zero-step mitigation if the vCPU that "wins" and gets delayed for
> whatever reason.
>
> Since FROZEN_SPTE is essentially bit-spinlock with a reaaaaaly slow slow-path,
> what if instead of resuming the guest if a page fault hits FROZEN_SPTE, KVM retries
> the fault "locally", i.e. _without_ redoing tdh_vp_enter() to see if the vCPU still
> hits the fault?
>
> For non-TDX, resuming the guest and letting the vCPU retry the instruction is
> desirable because in many cases, the winning task will install a valid mapping
> before KVM can re-run the vCPU, i.e. the fault will be fixed before the
> instruction is re-executed. In the happy case, that provides optimal performance
> as KVM doesn't introduce any extra delay/latency.
>
> But for TDX, the math is different as the cost of a re-hitting a fault is much,
> much higher, especially in light of the zero-step issues.
>
> E.g. if the TDP MMU returns a unique error code for the frozen case, and
> kvm_mmu_page_fault() is modified to return the raw return code instead of '1',
> then the TDX EPT violation path can safely retry locally, similar to the do-while
> loop in kvm_tdp_map_page().
>
> The only part I don't like about this idea is having two "retry" return values,
> which creates the potential for bugs due to checking one but not the other.
>
> Hmm, that could be avoided by passing a bool pointer as an out-param to communicate
> to the TDX S-EPT fault handler that the SPTE is frozen. I think I like that
> option better even though the out-param is a bit gross, because it makes it more
> obvious that the "frozen_spte" is a special case that doesn't need attention for
> most paths.
Good idea.
But could we extend it a bit more to allow TDX's EPT violation handler to also
retry directly when tdh_mem_sept_add()/tdh_mem_page_aug() returns BUSY?
>
> > - tdg_mem_page_accept() can contend with other tdh_mem*().
> >
> > Proposal:
> > - Return -EAGAIN directly in ops link_external_spt/set_external_spte when
> > tdh_mem_sept_add()/tdh_mem_page_aug() returns BUSY.
> What is the result of returning -EAGAIN? E.g. does KVM redo tdh_vp_enter()?
Sorry, I meant -EBUSY originally.
With the current code in kvm_tdp_map_page(), vCPU should just retry without
tdh_vp_enter() except when there're signals pending.
With a real EPT violation, tdh_vp_enter() should be called again.
I realized that this is not good enough.
So, is it better to return -EAGAIN in ops link_external_spt/set_external_spte
and have kvm_tdp_mmu_map() return RET_PF_RETRY_FROZEN for -EAGAIN?
(or maybe some other name for RET_PF_RETRY_FROZEN).
> Also tdh_mem_sept_add() is strictly pre-finalize, correct? I.e. should never
> contend with tdg_mem_page_accept() because vCPUs can't yet be run.
tdh_mem_page_add() is pre-finalize, tdh_mem_sept_add() is not.
tdh_mem_sept_add() can be called runtime by tdp_mmu_link_sp().
> Similarly, can tdh_mem_page_aug() actually contend with tdg_mem_page_accept()?
> The page isn't yet mapped, so why would the guest be allowed to take a lock on
> the S-EPT entry?
Before tdg_mem_page_accept() accepts a gpa and set rwx bits in a SPTE, if second
tdh_mem_page_aug() is called on the same gpa, the second one may contend with
tdg_mem_page_accept().
But given KVM does not allow the second tdh_mem_page_aug(), looks the contention
between tdh_mem_page_aug() and tdg_mem_page_accept() will not happen.
>
> > - Kick off vCPUs at the beginning of page removal path, i.e. before the
> > tdh_mem_range_block().
> > Set a flag and disallow tdh_vp_enter() until tdh_mem_page_remove() is done.
>
> This is easy enough to do via a request, e.g. see KVM_REQ_MCLOCK_INPROGRESS.
Great!
>
> > (one possible optimization:
> > since contention from tdh_vp_enter()/tdg_mem_page_accept should be rare,
> > do not kick off vCPUs in normal conditions.
> > When SEAMCALL BUSY happens, retry for once, kick off vCPUs and do not allow
>
> Which SEAMCALL is this specifically? tdh_mem_range_block()?
Yes, they are
- tdh_mem_range_block() contends with tdh_vp_enter() for secure_ept_lock.
- tdh_mem_track() contends with tdh_vp_enter() for TD epoch.
(current code in MMU part 2 just retry tdh_mem_track() endlessly),
- tdh_mem_page_remove()/tdh_mem_range_block() contends with
tdg_mem_page_accept() for SEPT entry lock.
(this one should not happen on a sane guest).
Resources SHARED users EXCLUSIVE users
------------------------------------------------------------------------
(5) TDCS epoch tdh_vp_enter tdh_mem_track
------------------------------------------------------------------------
(6) secure_ept_lock tdh_mem_sept_add tdh_vp_enter
tdh_mem_page_aug tdh_mem_sept_remove
tdh_mem_page_remove tdh_mem_range_block
tdh_mem_range_unblock
------------------------------------------------------------------------
(7) SEPT entry tdh_mem_sept_add
tdh_mem_sept_remove
tdh_mem_page_aug
tdh_mem_page_remove
tdh_mem_range_block
tdh_mem_range_unblock
tdg_mem_page_accept
>
> > TD enter until page removal completes.)
>
>
> Idea #1:
> ---
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index b45258285c9c..8113c17bd2f6 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -4719,7 +4719,7 @@ static int kvm_tdp_map_page(struct kvm_vcpu *vcpu, gpa_t gpa, u64 error_code,
> return -EINTR;
> cond_resched();
> r = kvm_mmu_do_page_fault(vcpu, gpa, error_code, true, NULL, level);
> - } while (r == RET_PF_RETRY);
> + } while (r == RET_PF_RETRY || r == RET_PF_RETRY_FOZEN);
>
> if (r < 0)
> return r;
> @@ -6129,7 +6129,7 @@ int noinline kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, u64 err
> vcpu->stat.pf_spurious++;
>
> if (r != RET_PF_EMULATE)
> - return 1;
> + return r;
>
> emulate:
> return x86_emulate_instruction(vcpu, cr2_or_gpa, emulation_type, insn,
> diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h
> index 8d3fb3c8c213..690f03d7daae 100644
> --- a/arch/x86/kvm/mmu/mmu_internal.h
> +++ b/arch/x86/kvm/mmu/mmu_internal.h
> @@ -256,12 +256,15 @@ int kvm_tdp_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault);
> * and of course kvm_mmu_do_page_fault().
> *
> * RET_PF_CONTINUE: So far, so good, keep handling the page fault.
> + * RET_PF_FIXED: The faulting entry has been fixed.
> * RET_PF_RETRY: let CPU fault again on the address.
> + * RET_PF_RETRY_FROZEN: One or more SPTEs related to the address is frozen.
> + * Let the CPU fault again on the address, or retry the
> + * fault "locally", i.e. without re-entering the guest.
> * RET_PF_EMULATE: mmio page fault, emulate the instruction directly.
> * RET_PF_WRITE_PROTECTED: the gfn is write-protected, either unprotected the
> * gfn and retry, or emulate the instruction directly.
> * RET_PF_INVALID: the spte is invalid, let the real page fault path update it.
> - * RET_PF_FIXED: The faulting entry has been fixed.
> * RET_PF_SPURIOUS: The faulting entry was already fixed, e.g. by another vCPU.
> *
> * Any names added to this enum should be exported to userspace for use in
> @@ -271,14 +274,18 @@ int kvm_tdp_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault);
> * on -errno return values. Somewhat arbitrarily use '0' for CONTINUE, which
> * will allow for efficient machine code when checking for CONTINUE, e.g.
> * "TEST %rax, %rax, JNZ", as all "stop!" values are non-zero.
> + *
> + * Note #2, RET_PF_FIXED _must_ be '1', so that KVM's -errno/0/1 return code
> + * scheme, where 1==success, translates '1' to RET_PF_FIXED.
> */
Looks "r > 0" represents success in vcpu_run()?
So, moving RET_PF_FIXED to 1 is not necessary?
> enum {
> RET_PF_CONTINUE = 0,
> + RET_PF_FIXED = 1,
> RET_PF_RETRY,
> + RET_PF_RETRY_FROZEN,
> RET_PF_EMULATE,
> RET_PF_WRITE_PROTECTED,
> RET_PF_INVALID,
> - RET_PF_FIXED,
> RET_PF_SPURIOUS,
> };
>
> diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> index 5a475a6456d4..cbf9e46203f3 100644
> --- a/arch/x86/kvm/mmu/tdp_mmu.c
> +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> @@ -1174,6 +1174,8 @@ int kvm_tdp_mmu_map(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
>
> retry:
> rcu_read_unlock();
> + if (ret == RET_PF_RETRY && is_frozen_spte(iter.old_spte))
> + return RET_PF_RETRY_FOZEN;
> return ret;
> }
>
> ---
>
>
> Idea #2:
> ---
> arch/x86/include/asm/kvm_host.h | 2 +-
> arch/x86/kvm/mmu/mmu.c | 12 ++++++------
> arch/x86/kvm/mmu/mmu_internal.h | 15 ++++++++++++---
> arch/x86/kvm/mmu/tdp_mmu.c | 1 +
> arch/x86/kvm/svm/svm.c | 2 +-
> arch/x86/kvm/vmx/vmx.c | 4 ++--
> 6 files changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 46e0a466d7fb..200fecd1de88 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -2183,7 +2183,7 @@ unsigned long __kvm_emulate_hypercall(struct kvm_vcpu *vcpu, unsigned long nr,
> int kvm_emulate_hypercall(struct kvm_vcpu *vcpu);
>
> int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, u64 error_code,
> - void *insn, int insn_len);
> + void *insn, int insn_len, bool *frozen_spte);
> void kvm_mmu_print_sptes(struct kvm_vcpu *vcpu, gpa_t gpa, const char *msg);
> void kvm_mmu_invlpg(struct kvm_vcpu *vcpu, gva_t gva);
> void kvm_mmu_invalidate_addr(struct kvm_vcpu *vcpu, struct kvm_mmu *mmu,
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index b45258285c9c..207840a316d3 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -4283,7 +4283,7 @@ void kvm_arch_async_page_ready(struct kvm_vcpu *vcpu, struct kvm_async_pf *work)
> return;
>
> r = kvm_mmu_do_page_fault(vcpu, work->cr2_or_gpa, work->arch.error_code,
> - true, NULL, NULL);
> + true, NULL, NULL, NULL);
>
> /*
> * Account fixed page faults, otherwise they'll never be counted, but
> @@ -4627,7 +4627,7 @@ int kvm_handle_page_fault(struct kvm_vcpu *vcpu, u64 error_code,
> trace_kvm_page_fault(vcpu, fault_address, error_code);
>
> r = kvm_mmu_page_fault(vcpu, fault_address, error_code, insn,
> - insn_len);
> + insn_len, NULL);
> } else if (flags & KVM_PV_REASON_PAGE_NOT_PRESENT) {
> vcpu->arch.apf.host_apf_flags = 0;
> local_irq_disable();
> @@ -4718,7 +4718,7 @@ static int kvm_tdp_map_page(struct kvm_vcpu *vcpu, gpa_t gpa, u64 error_code,
> if (signal_pending(current))
> return -EINTR;
> cond_resched();
> - r = kvm_mmu_do_page_fault(vcpu, gpa, error_code, true, NULL, level);
> + r = kvm_mmu_do_page_fault(vcpu, gpa, error_code, true, NULL, level, NULL);
> } while (r == RET_PF_RETRY);
>
> if (r < 0)
> @@ -6073,7 +6073,7 @@ static int kvm_mmu_write_protect_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
> }
>
> int noinline kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, u64 error_code,
> - void *insn, int insn_len)
> + void *insn, int insn_len, bool *frozen_spte)
> {
> int r, emulation_type = EMULTYPE_PF;
> bool direct = vcpu->arch.mmu->root_role.direct;
> @@ -6109,7 +6109,7 @@ int noinline kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, u64 err
> vcpu->stat.pf_taken++;
>
> r = kvm_mmu_do_page_fault(vcpu, cr2_or_gpa, error_code, false,
> - &emulation_type, NULL);
> + &emulation_type, NULL, frozen_spte);
> if (KVM_BUG_ON(r == RET_PF_INVALID, vcpu->kvm))
> return -EIO;
> }
> @@ -6129,7 +6129,7 @@ int noinline kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, u64 err
> vcpu->stat.pf_spurious++;
>
> if (r != RET_PF_EMULATE)
> - return 1;
> + return r;
>
> emulate:
> return x86_emulate_instruction(vcpu, cr2_or_gpa, emulation_type, insn,
> diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h
> index 8d3fb3c8c213..5b1fc77695c1 100644
> --- a/arch/x86/kvm/mmu/mmu_internal.h
> +++ b/arch/x86/kvm/mmu/mmu_internal.h
> @@ -247,6 +247,9 @@ struct kvm_page_fault {
> * is changing its own translation in the guest page tables.
> */
> bool write_fault_to_shadow_pgtable;
> +
> + /* Indicates the page fault needs to be retried due to a frozen SPTE. */
> + bool frozen_spte;
> };
>
> int kvm_tdp_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault);
> @@ -256,12 +259,12 @@ int kvm_tdp_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault);
> * and of course kvm_mmu_do_page_fault().
> *
> * RET_PF_CONTINUE: So far, so good, keep handling the page fault.
> + * RET_PF_FIXED: The faulting entry has been fixed.
> * RET_PF_RETRY: let CPU fault again on the address.
> * RET_PF_EMULATE: mmio page fault, emulate the instruction directly.
> * RET_PF_WRITE_PROTECTED: the gfn is write-protected, either unprotected the
> * gfn and retry, or emulate the instruction directly.
> * RET_PF_INVALID: the spte is invalid, let the real page fault path update it.
> - * RET_PF_FIXED: The faulting entry has been fixed.
> * RET_PF_SPURIOUS: The faulting entry was already fixed, e.g. by another vCPU.
> *
> * Any names added to this enum should be exported to userspace for use in
> @@ -271,14 +274,17 @@ int kvm_tdp_page_fault(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault);
> * on -errno return values. Somewhat arbitrarily use '0' for CONTINUE, which
> * will allow for efficient machine code when checking for CONTINUE, e.g.
> * "TEST %rax, %rax, JNZ", as all "stop!" values are non-zero.
> + *
> + * Note #2, RET_PF_FIXED _must_ be '1', so that KVM's -errno/0/1 return code
> + * scheme, where 1==success, translates '1' to RET_PF_FIXED.
> */
> enum {
> RET_PF_CONTINUE = 0,
> + RET_PF_FIXED = 1,
> RET_PF_RETRY,
> RET_PF_EMULATE,
> RET_PF_WRITE_PROTECTED,
> RET_PF_INVALID,
> - RET_PF_FIXED,
> RET_PF_SPURIOUS,
> };
>
> @@ -292,7 +298,8 @@ static inline void kvm_mmu_prepare_memory_fault_exit(struct kvm_vcpu *vcpu,
>
> static inline int kvm_mmu_do_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
> u64 err, bool prefetch,
> - int *emulation_type, u8 *level)
> + int *emulation_type, u8 *level,
> + bool *frozen_spte)
> {
> struct kvm_page_fault fault = {
> .addr = cr2_or_gpa,
> @@ -341,6 +348,8 @@ static inline int kvm_mmu_do_page_fault(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa,
> *emulation_type |= EMULTYPE_WRITE_PF_TO_SP;
> if (level)
> *level = fault.goal_level;
> + if (frozen_spte)
> + *frozen_spte = fault.frozen_spte;
>
> return r;
> }
> diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> index 5a475a6456d4..e7fc5ea4b437 100644
> --- a/arch/x86/kvm/mmu/tdp_mmu.c
> +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> @@ -1174,6 +1174,7 @@ int kvm_tdp_mmu_map(struct kvm_vcpu *vcpu, struct kvm_page_fault *fault)
>
> retry:
> rcu_read_unlock();
> + fault->frozen_spte = is_frozen_spte(iter.old_spte);
> return ret;
> }
>
> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 38723b0c435d..269de6a9eb13 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -2075,7 +2075,7 @@ static int npf_interception(struct kvm_vcpu *vcpu)
> rc = kvm_mmu_page_fault(vcpu, fault_address, error_code,
> static_cpu_has(X86_FEATURE_DECODEASSISTS) ?
> svm->vmcb->control.insn_bytes : NULL,
> - svm->vmcb->control.insn_len);
> + svm->vmcb->control.insn_len, NULL);
>
> if (rc > 0 && error_code & PFERR_GUEST_RMP_MASK)
> sev_handle_rmp_fault(vcpu, fault_address, error_code);
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index 368acfebd476..fc2ff5d91a71 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -5822,7 +5822,7 @@ static int handle_ept_violation(struct kvm_vcpu *vcpu)
> if (unlikely(allow_smaller_maxphyaddr && !kvm_vcpu_is_legal_gpa(vcpu, gpa)))
> return kvm_emulate_instruction(vcpu, 0);
>
> - return kvm_mmu_page_fault(vcpu, gpa, error_code, NULL, 0);
> + return kvm_mmu_page_fault(vcpu, gpa, error_code, NULL, 0, NULL);
> }
>
> static int handle_ept_misconfig(struct kvm_vcpu *vcpu)
> @@ -5843,7 +5843,7 @@ static int handle_ept_misconfig(struct kvm_vcpu *vcpu)
> return kvm_skip_emulated_instruction(vcpu);
> }
>
> - return kvm_mmu_page_fault(vcpu, gpa, PFERR_RSVD_MASK, NULL, 0);
> + return kvm_mmu_page_fault(vcpu, gpa, PFERR_RSVD_MASK, NULL, 0, NULL);
> }
>
> static int handle_nmi_window(struct kvm_vcpu *vcpu)
>
> base-commit: bc87a2b4b5508d247ed2c30cd2829969d168adfe
> --
>
next prev parent reply other threads:[~2024-09-14 9:29 UTC|newest]
Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 3:07 [PATCH 00/21] TDX MMU Part 2 Rick Edgecombe
2024-09-04 3:07 ` [PATCH 01/21] KVM: x86/mmu: Implement memslot deletion for TDX Rick Edgecombe
2024-09-09 13:44 ` Paolo Bonzini
2024-09-09 21:06 ` Edgecombe, Rick P
2024-09-04 3:07 ` [PATCH 02/21] KVM: x86/tdp_mmu: Add a helper function to walk down the TDP MMU Rick Edgecombe
2024-09-09 13:51 ` Paolo Bonzini
2024-09-04 3:07 ` [PATCH 03/21] KVM: x86/mmu: Do not enable page track for TD guest Rick Edgecombe
2024-09-09 13:53 ` Paolo Bonzini
2024-09-09 21:07 ` Edgecombe, Rick P
2024-09-04 3:07 ` [PATCH 04/21] KVM: VMX: Split out guts of EPT violation to common/exposed function Rick Edgecombe
2024-09-09 13:57 ` Paolo Bonzini
2024-09-09 16:07 ` Sean Christopherson
2024-09-10 7:36 ` Paolo Bonzini
2024-09-04 3:07 ` [PATCH 05/21] KVM: VMX: Teach EPT violation helper about private mem Rick Edgecombe
2024-09-09 13:59 ` Paolo Bonzini
2024-09-11 8:52 ` Chao Gao
2024-09-11 16:29 ` Edgecombe, Rick P
2024-09-12 0:39 ` Huang, Kai
2024-09-12 13:58 ` Sean Christopherson
2024-09-12 14:43 ` Edgecombe, Rick P
2024-09-12 14:46 ` Paolo Bonzini
2024-09-12 1:19 ` Huang, Kai
2024-09-04 3:07 ` [PATCH 06/21] KVM: TDX: Add accessors VMX VMCS helpers Rick Edgecombe
2024-09-09 14:19 ` Paolo Bonzini
2024-09-09 21:29 ` Edgecombe, Rick P
2024-09-10 10:48 ` Paolo Bonzini
2024-09-04 3:07 ` [PATCH 07/21] KVM: TDX: Add load_mmu_pgd method for TDX Rick Edgecombe
2024-09-11 2:48 ` Chao Gao
2024-09-11 2:49 ` Edgecombe, Rick P
2024-09-04 3:07 ` [PATCH 08/21] KVM: TDX: Set gfn_direct_bits to shared bit Rick Edgecombe
2024-09-09 15:21 ` Paolo Bonzini
2024-09-04 3:07 ` [PATCH 09/21] KVM: TDX: Retry seamcall when TDX_OPERAND_BUSY with operand SEPT Rick Edgecombe
2024-09-06 1:41 ` Huang, Kai
2024-09-09 20:25 ` Edgecombe, Rick P
2024-09-09 15:25 ` Paolo Bonzini
2024-09-09 20:22 ` Edgecombe, Rick P
2024-09-09 21:11 ` Sean Christopherson
2024-09-09 21:23 ` Sean Christopherson
2024-09-09 22:34 ` Edgecombe, Rick P
2024-09-09 23:58 ` Sean Christopherson
2024-09-10 0:50 ` Edgecombe, Rick P
2024-09-10 1:46 ` Sean Christopherson
2024-09-11 1:17 ` Huang, Kai
2024-09-11 2:48 ` Edgecombe, Rick P
2024-09-11 22:55 ` Huang, Kai
2024-09-10 13:15 ` Paolo Bonzini
2024-09-10 13:57 ` Sean Christopherson
2024-09-10 15:16 ` Paolo Bonzini
2024-09-10 15:57 ` Sean Christopherson
2024-09-10 16:28 ` Edgecombe, Rick P
2024-09-10 17:42 ` Sean Christopherson
2024-09-13 8:36 ` Yan Zhao
2024-09-13 17:23 ` Sean Christopherson
2024-09-13 19:19 ` Edgecombe, Rick P
2024-09-13 22:18 ` Sean Christopherson
2024-09-14 9:27 ` Yan Zhao [this message]
2024-09-15 9:53 ` Yan Zhao
2024-09-17 1:31 ` Huang, Kai
2024-09-25 10:53 ` Yan Zhao
2024-10-08 14:51 ` Sean Christopherson
2024-10-10 5:23 ` Yan Zhao
2024-10-10 17:33 ` Sean Christopherson
2024-10-10 21:53 ` Edgecombe, Rick P
2024-10-11 2:30 ` Yan Zhao
2024-10-14 10:54 ` Huang, Kai
2024-10-14 17:36 ` Edgecombe, Rick P
2024-10-14 23:03 ` Huang, Kai
2024-10-15 1:24 ` Edgecombe, Rick P
2024-10-11 2:06 ` Yan Zhao
2024-10-16 14:13 ` Yan Zhao
2024-09-17 2:11 ` Huang, Kai
2024-09-13 19:19 ` Edgecombe, Rick P
2024-09-14 10:00 ` Yan Zhao
2024-09-04 3:07 ` [PATCH 10/21] KVM: TDX: Require TDP MMU and mmio caching for TDX Rick Edgecombe
2024-09-09 15:26 ` Paolo Bonzini
2024-09-12 0:15 ` Huang, Kai
2024-09-04 3:07 ` [PATCH 11/21] KVM: x86/mmu: Add setter for shadow_mmio_value Rick Edgecombe
2024-09-09 15:33 ` Paolo Bonzini
2024-09-04 3:07 ` [PATCH 12/21] KVM: TDX: Set per-VM shadow_mmio_value to 0 Rick Edgecombe
2024-09-09 15:33 ` Paolo Bonzini
2024-09-04 3:07 ` [PATCH 13/21] KVM: TDX: Handle TLB tracking for TDX Rick Edgecombe
2024-09-10 8:16 ` Paolo Bonzini
2024-09-10 23:49 ` Edgecombe, Rick P
2024-10-14 6:34 ` Yan Zhao
2024-09-11 6:25 ` Xu Yilun
2024-09-11 17:28 ` Edgecombe, Rick P
2024-09-12 4:54 ` Yan Zhao
2024-09-12 14:44 ` Edgecombe, Rick P
2024-09-12 7:47 ` Xu Yilun
2024-09-04 3:07 ` [PATCH 14/21] KVM: TDX: Implement hooks to propagate changes of TDP MMU mirror page table Rick Edgecombe
2024-09-06 2:10 ` Huang, Kai
2024-09-09 21:03 ` Edgecombe, Rick P
2024-09-10 1:52 ` Yan Zhao
2024-09-10 9:33 ` Paolo Bonzini
2024-09-10 23:58 ` Edgecombe, Rick P
2024-09-11 1:05 ` Yan Zhao
2024-10-30 3:03 ` Binbin Wu
2024-11-04 9:09 ` Yan Zhao
2024-09-04 3:07 ` [PATCH 15/21] KVM: TDX: Implement hook to get max mapping level of private pages Rick Edgecombe
2024-09-10 10:17 ` Paolo Bonzini
2024-09-04 3:07 ` [PATCH 16/21] KVM: TDX: Premap initial guest memory Rick Edgecombe
2024-09-10 10:24 ` Paolo Bonzini
2024-09-11 0:19 ` Edgecombe, Rick P
2024-09-13 13:33 ` Adrian Hunter
2024-09-13 19:49 ` Edgecombe, Rick P
2024-09-10 10:49 ` Paolo Bonzini
2024-09-11 0:30 ` Edgecombe, Rick P
2024-09-11 10:39 ` Paolo Bonzini
2024-09-11 16:36 ` Edgecombe, Rick P
2024-09-04 3:07 ` [PATCH 17/21] KVM: TDX: MTRR: implement get_mt_mask() for TDX Rick Edgecombe
2024-09-10 10:04 ` Paolo Bonzini
2024-09-10 14:05 ` Sean Christopherson
2024-09-04 3:07 ` [PATCH 18/21] KVM: x86/mmu: Export kvm_tdp_map_page() Rick Edgecombe
2024-09-10 10:02 ` Paolo Bonzini
2024-09-04 3:07 ` [PATCH 19/21] KVM: TDX: Add an ioctl to create initial guest memory Rick Edgecombe
2024-09-04 4:53 ` Yan Zhao
2024-09-04 14:01 ` Edgecombe, Rick P
2024-09-06 16:30 ` Edgecombe, Rick P
2024-09-09 1:29 ` Yan Zhao
2024-09-10 10:13 ` Paolo Bonzini
2024-09-11 0:11 ` Edgecombe, Rick P
2024-09-04 13:56 ` Edgecombe, Rick P
2024-09-10 10:16 ` Paolo Bonzini
2024-09-11 0:12 ` Edgecombe, Rick P
2024-09-04 3:07 ` [PATCH 20/21] KVM: TDX: Finalize VM initialization Rick Edgecombe
2024-09-04 15:37 ` Adrian Hunter
2024-09-04 16:09 ` Edgecombe, Rick P
2024-09-10 10:33 ` Paolo Bonzini
2024-09-10 11:15 ` Adrian Hunter
2024-09-10 11:28 ` Paolo Bonzini
2024-09-10 11:31 ` Adrian Hunter
2024-09-10 10:25 ` Paolo Bonzini
2024-09-10 11:54 ` Adrian Hunter
2024-09-04 3:07 ` [PATCH 21/21] KVM: TDX: Handle vCPU dissociation Rick Edgecombe
2024-09-09 15:41 ` Paolo Bonzini
2024-09-09 23:30 ` Edgecombe, Rick P
2024-09-10 10:45 ` Paolo Bonzini
2024-09-11 0:17 ` Edgecombe, Rick P
2024-11-04 9:45 ` Yan Zhao
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=ZuVXBDCWS615bsVa@yzhao56-desk.sh.intel.com \
--to=yan.y.zhao@intel.com \
--cc=dmatlack@google.com \
--cc=isaku.yamahata@gmail.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=yuan.yao@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox