All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yan Zhao <yan.y.zhao@intel.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "quic_eberman@quicinc.com" <quic_eberman@quicinc.com>,
	"Li, Xiaoyao" <xiaoyao.li@intel.com>,
	"Huang, Kai" <kai.huang@intel.com>, "Du, Fan" <fan.du@intel.com>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"david@redhat.com" <david@redhat.com>,
	"thomas.lendacky@amd.com" <thomas.lendacky@amd.com>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"Li, Zhiquan1" <zhiquan1.li@intel.com>,
	"Shutemov, Kirill" <kirill.shutemov@intel.com>,
	"michael.roth@amd.com" <michael.roth@amd.com>,
	"seanjc@google.com" <seanjc@google.com>,
	"Weiny, Ira" <ira.weiny@intel.com>,
	"Peng, Chao P" <chao.p.peng@intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"Yamahata, Isaku" <isaku.yamahata@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>,
	"ackerleytng@google.com" <ackerleytng@google.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"Annapurve, Vishal" <vannapurve@google.com>,
	"tabba@google.com" <tabba@google.com>,
	"jroedel@suse.de" <jroedel@suse.de>,
	"Miao, Jun" <jun.miao@intel.com>,
	"pgonda@google.com" <pgonda@google.com>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [RFC PATCH 09/21] KVM: TDX: Enable 2MB mapping size after TD is RUNNABLE
Date: Tue, 1 Jul 2025 10:41:30 +0800	[thread overview]
Message-ID: <aGNK2tO2W6+GWtt3@yzhao56-desk.sh.intel.com> (raw)
In-Reply-To: <dab82e2c91c8ad019cda835ef8d528a7101509fa.camel@intel.com>

On Tue, Jul 01, 2025 at 08:42:33AM +0800, Edgecombe, Rick P wrote:
> On Thu, 2025-06-26 at 16:53 +0800, Yan Zhao wrote:
> > On Wed, Jun 25, 2025 at 10:47:47PM +0800, Edgecombe, Rick P wrote:
> > > On Wed, 2025-06-25 at 17:28 +0800, Yan Zhao wrote:
> > > > On Wed, Jun 25, 2025 at 02:35:59AM +0800, Edgecombe, Rick P wrote:
> > > > > On Tue, 2025-06-24 at 17:57 +0800, Yan Zhao wrote:
> > > > > 
> > > > I guess it's the latter one as it can avoid modification to both EDK2 and Linux
> > > > guest.  I observed ~2710 instances of "guest accepts at 4KB when KVM can map at
> > > > 2MB" during the boot-up of a TD with 4GB memory.
> > > 
> > > Oh, wow that is more than I expected. Did you notice how many vCPUs they were
> > > spread across? What memory size did you use? What was your guest memory
> > > configuration?
> > The guest memory is 4GB, 8 vCPUs.
> > The memory slots layout is:
> > slot 1: base gfn=0, npages=0x80000
> > slot 2: base gfn=0x100000, npages=0x80000
> > slot 3: base gfn=0xffc00, npages=0x400
> > 
> > The GFN spread for the ~2710 instances is:
> > GFNs 0x806-0x9ff (1 time for each of 506 pages)
> > GFNs 0x7e800-0x7e9ff (1 time for each of 512 pages)
> > GFN: 0x7d3ff~0x7e7fe (repeated private-to-shared, and shared-to-private are
> >                       conducted on this range), with the top 3 among them being:
> >      0x7d9da (476 times)
> >      0x7d9d9 (156 times)
> >      0x7d9d7 (974 times)
> > 
> > All those instances are from vCPU 0, when the guest is in EDK2 and during early
> > kernel boot.
> > 
> > Based on my observation, the count of these instances does not scale with guest
> > memory. In other words, the count remains roughly the same even when the guest
> > memory is increased to 8GB.
> 
> So the impact would be negligible. The mmu write lock would not meet much, if
> any, contention.
> 
> > 
> > > > But does it mean TDX needs to hold write mmu_lock in the EPT violation handler
> > > > and set KVM_LPAGE_GUEST_INHIBIT on finding a violation carries 4KB level info?
> > > 
> > > I think so. I didn't check the reason, but the other similar code took it. Maybe
> > > not? If we don't need to take mmu write lock, then this idea seems like a clear
> > > winner to me.
> > Hmm,  setting KVM_LPAGE_GUEST_INHIBIT needs trying splitting to be followed.
> > So, if we don't want to support splitting under read mmu_lock, we need to take
> > write mmu_lock.
> > 
> > I drafted a change as below (will refine some parts of it later).
> > The average count to take write mmu_lock is 11 during VM boot.
> > 
> > There's no signiticant difference in the count of 2M mappings
> > During guest kerne booting to login, on average: 
> > before this patch: 1144 2M mappings 
> > after this patch:  1143 2M mappings.
> 
> Oh, hmm. Well, it's not strong argument against.
> 
> > 
> > diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
> > index f999c15d8d3e..d4e98728f600 100644
> > --- a/arch/x86/kvm/mmu.h
> > +++ b/arch/x86/kvm/mmu.h
> > @@ -322,4 +322,8 @@ static inline bool kvm_is_gfn_alias(struct kvm *kvm, gfn_t gfn)
> >  {
> >         return gfn & kvm_gfn_direct_bits(kvm);
> >  }
> > +
> > +void hugepage_set_guest_inhibit(struct kvm_memory_slot *slot, gfn_t gfn, int level);
> > +bool hugepage_test_guest_inhibit(struct kvm_memory_slot *slot, gfn_t gfn, int level);
> > +
> >  #endif
> > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> > index f0afee2e283a..28c511d8b372 100644
> > --- a/arch/x86/kvm/mmu/mmu.c
> > +++ b/arch/x86/kvm/mmu/mmu.c
> > @@ -721,6 +721,8 @@ static struct kvm_lpage_info *lpage_info_slot(gfn_t gfn,
> >   */
> >  #define KVM_LPAGE_MIXED_FLAG   BIT(31)
> > 
> > +#define KVM_LPAGE_GUEST_INHIBIT_FLAG   BIT(30)
> > +
> >  static void update_gfn_disallow_lpage_count(const struct kvm_memory_slot *slot,
> >                                             gfn_t gfn, int count)
> >  {
> > @@ -732,7 +734,8 @@ static void update_gfn_disallow_lpage_count(const struct kvm_memory_slot *slot,
> > 
> >                 old = linfo->disallow_lpage;
> >                 linfo->disallow_lpage += count;
> > -               WARN_ON_ONCE((old ^ linfo->disallow_lpage) & KVM_LPAGE_MIXED_FLAG);
> > +               WARN_ON_ONCE((old ^ linfo->disallow_lpage) &
> > +                             (KVM_LPAGE_MIXED_FLAG | KVM_LPAGE_GUEST_INHIBIT_FLAG));
> >         }
> >  }
> > 
> > @@ -1653,13 +1656,15 @@ int kvm_split_boundary_leafs(struct kvm *kvm, struct kvm_gfn_range *range)
> >         bool ret = 0;
> > 
> >         lockdep_assert_once(kvm->mmu_invalidate_in_progress ||
> > -                           lockdep_is_held(&kvm->slots_lock));
> > +                           lockdep_is_held(&kvm->slots_lock) ||
> > +                           srcu_read_lock_held(&kvm->srcu));
> > 
> >         if (tdp_mmu_enabled)
> >                 ret = kvm_tdp_mmu_gfn_range_split_boundary(kvm, range);
> > 
> >         return ret;
> >  }
> > +EXPORT_SYMBOL_GPL(kvm_split_boundary_leafs);
> > 
> >  bool kvm_unmap_gfn_range(struct kvm *kvm, struct kvm_gfn_range *range)
> >  {
> > @@ -7734,6 +7739,18 @@ void kvm_mmu_pre_destroy_vm(struct kvm *kvm)
> >                 vhost_task_stop(kvm->arch.nx_huge_page_recovery_thread);
> >  }
> > 
> > +bool hugepage_test_guest_inhibit(struct kvm_memory_slot *slot, gfn_t gfn, int level)
> > +{
> > +       return lpage_info_slot(gfn, slot, level)->disallow_lpage & KVM_LPAGE_GUEST_INHIBIT_FLAG;
> > +}
> > +EXPORT_SYMBOL_GPL(hugepage_test_guest_inhibit);
> > +
> > +void hugepage_set_guest_inhibit(struct kvm_memory_slot *slot, gfn_t gfn, int level)
> > +{
> > +       lpage_info_slot(gfn, slot, level)->disallow_lpage |= KVM_LPAGE_GUEST_INHIBIT_FLAG;
> > +}
> > +EXPORT_SYMBOL_GPL(hugepage_set_guest_inhibit);
> > +
> >  #ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> >  static bool hugepage_test_mixed(struct kvm_memory_slot *slot, gfn_t gfn,
> >                                 int level)
> > diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> > index 244fd22683db..4028423cf595 100644
> > --- a/arch/x86/kvm/vmx/tdx.c
> > +++ b/arch/x86/kvm/vmx/tdx.c
> > @@ -1852,28 +1852,8 @@ int tdx_sept_split_private_spt(struct kvm *kvm, gfn_t gfn, enum pg_level level,
> >         if (KVM_BUG_ON(to_kvm_tdx(kvm)->state != TD_STATE_RUNNABLE || level != PG_LEVEL_2M, kvm))
> >                 return -EINVAL;
> > 
> > -       /*
> > -        * Split request with mmu_lock held for reading can only occur when one
> > -        * vCPU accepts at 2MB level while another vCPU accepts at 4KB level.
> > -        * Ignore this 4KB mapping request by setting violation_request_level to
> > -        * 2MB and returning -EBUSY for retry. Then the next fault at 2MB level
> > -        * would be a spurious fault. The vCPU accepting at 2MB will accept the
> > -        * whole 2MB range.
> > -        */
> > -       if (mmu_lock_shared) {
> > -               struct kvm_vcpu *vcpu = kvm_get_running_vcpu();
> > -               struct vcpu_tdx *tdx = to_tdx(vcpu);
> > -
> > -               if (KVM_BUG_ON(!vcpu, kvm))
> > -                       return -EOPNOTSUPP;
> > -
> > -               /* Request to map as 2MB leaf for the whole 2MB range */
> > -               tdx->violation_gfn_start = gfn_round_for_level(gfn, level);
> > -               tdx->violation_gfn_end = tdx->violation_gfn_start + KVM_PAGES_PER_HPAGE(level);
> > -               tdx->violation_request_level = level;
> > -
> > -               return -EBUSY;
> > -       }
> > +       if (mmu_lock_shared)
> > +               return -EOPNOTSUPP;
> > 
> >         ret = tdx_sept_zap_private_spte(kvm, gfn, level, page);
> >         if (ret <= 0)
> > @@ -1937,28 +1917,51 @@ static inline bool tdx_is_sept_violation_unexpected_pending(struct kvm_vcpu *vcp
> >         return !(eq & EPT_VIOLATION_PROT_MASK) && !(eq & EPT_VIOLATION_EXEC_FOR_RING3_LIN);
> >  }
> > 
> > -static inline void tdx_get_accept_level(struct kvm_vcpu *vcpu, gpa_t gpa)
> > +static inline int tdx_check_accept_level(struct kvm_vcpu *vcpu, gpa_t gpa)
> >  {
> >         struct vcpu_tdx *tdx = to_tdx(vcpu);
> > +       struct kvm *kvm = vcpu->kvm;
> > +       gfn_t gfn = gpa_to_gfn(gpa);
> > +       struct kvm_memory_slot *slot = kvm_vcpu_gfn_to_memslot(vcpu, gfn);
> >         int level = -1;
> > +       u64 eeq_info;
> > 
> > -       u64 eeq_type = tdx->ext_exit_qualification & TDX_EXT_EXIT_QUAL_TYPE_MASK;
> > +       if (!slot)
> > +               return 0;
> > 
> > -       u32 eeq_info = (tdx->ext_exit_qualification & TDX_EXT_EXIT_QUAL_INFO_MASK) >>
> > -                       TDX_EXT_EXIT_QUAL_INFO_SHIFT;
> > +       if ((tdx->ext_exit_qualification & TDX_EXT_EXIT_QUAL_TYPE_MASK) !=
> > +           TDX_EXT_EXIT_QUAL_TYPE_ACCEPT)
> > +               return 0;
> > 
> > -       if (eeq_type == TDX_EXT_EXIT_QUAL_TYPE_ACCEPT) {
> > -               level = (eeq_info & GENMASK(2, 0)) + 1;
> > +       eeq_info = (tdx->ext_exit_qualification & TDX_EXT_EXIT_QUAL_INFO_MASK) >>
> > +                   TDX_EXT_EXIT_QUAL_INFO_SHIFT;
> > 
> > -               tdx->violation_gfn_start = gfn_round_for_level(gpa_to_gfn(gpa), level);
> > -               tdx->violation_gfn_end = tdx->violation_gfn_start + KVM_PAGES_PER_HPAGE(level);
> > -               tdx->violation_request_level = level;
> > -       } else {
> > -               tdx->violation_gfn_start = -1;
> > -               tdx->violation_gfn_end = -1;
> > -               tdx->violation_request_level = -1;
> > +       level = (eeq_info & GENMASK(2, 0)) + 1;
> > +
> > +       if (level == PG_LEVEL_4K) {
> > +              if (!hugepage_test_guest_inhibit(slot, gfn, PG_LEVEL_2M)) {
> > +                       struct kvm_gfn_range gfn_range = {
> > +                               .start = gfn,
> > +                               .end = gfn + 1,
> > +                               .slot = slot,
> > +                               .may_block = true,
> > +                               .attr_filter = KVM_FILTER_PRIVATE,
> > +                       };
> > +
> > +                       scoped_guard(write_lock, &kvm->mmu_lock) {
> > +                               int ret;
> > +
> > +                               ret = kvm_split_boundary_leafs(kvm, &gfn_range);
> > +
> > +                               if (ret)
> > +                                       return ret;
> > +
> > +                               hugepage_set_guest_inhibit(slot, gfn, PG_LEVEL_2M);
> 
> 
> Can you explain what you found regarding the write lock need?
Here, the write lock protects 2 steps:
(1) update lpage_info.
(2) try splitting if there's any existing 2MB mapping.

The write mmu_lock is needed because lpage_info is read under read mmu_lock in
kvm_tdp_mmu_map().

kvm_tdp_mmu_map
  kvm_mmu_hugepage_adjust
    kvm_lpage_info_max_mapping_level

If we update the lpage_info with read mmu_lock, the other vCPUs may map at a
stale 2MB level even after lpage_info is updated by hugepage_set_guest_inhibit().

Therefore, we must perform splitting under the write mmu_lock to ensure there
are no 2MB mappings after hugepage_set_guest_inhibit().

Otherwise, during later mapping in __vmx_handle_ept_violation(), splitting at
fault path could be triggered as KVM MMU finds the goal level is 4KB while an
existing 2MB mapping is present.


> For most accept
> cases, we could fault in the PTE's on the read lock. And in the future we could

The actual mapping at 4KB level is still with read mmu_lock in
__vmx_handle_ept_violation().

> have a demote that could work under read lock, as we talked. So
> kvm_split_boundary_leafs() often or could be unneeded or work under read lock
> when needed.
Could we leave the "demote under read lock" as a future optimization? 


> What is the problem in hugepage_set_guest_inhibit() that requires the write
> lock?
As above, to avoid the other vCPUs reading stale mapping level and splitting
under read mmu_lock.

As guest_inhibit is set one-way, we could test it using
hugepage_test_guest_inhibit() without holding the lock. The chance to hold write
mmu_lock for hugepage_set_guest_inhibit() is then greatly reduced.
(in my testing, 11 during VM boot).
 
> But in any case, it seems like we have *a* solution here. It doesn't seem like
> there are any big downsides. Should we close it?
I think it's good, as long as Sean doesn't disagree :)


> > +                       }
> > +              }
> >         }
> > +
> > +       return 0;
> >  }
> > 
> >  static int tdx_handle_ept_violation(struct kvm_vcpu *vcpu)
> > @@ -1987,7 +1990,8 @@ static int tdx_handle_ept_violation(struct kvm_vcpu *vcpu)
> >                  */
> >                 exit_qual = EPT_VIOLATION_ACC_WRITE;
> > 
> > -               tdx_get_accept_level(vcpu, gpa);
> > +               if (tdx_check_accept_level(vcpu, gpa))
> > +                       return RET_PF_RETRY;
> > 
> >                 /* Only private GPA triggers zero-step mitigation */
> >                 local_retry = true;
> > @@ -3022,9 +3026,6 @@ static int tdx_td_vcpu_init(struct kvm_vcpu *vcpu, u64 vcpu_rcx)
> > 
> >         vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
> > 
> > -       tdx->violation_gfn_start = -1;
> > -       tdx->violation_gfn_end = -1;
> > -       tdx->violation_request_level = -1;
> >         return 0;
> > 
> >  free_tdcx:
> > @@ -3373,14 +3374,9 @@ int tdx_vcpu_ioctl(struct kvm_vcpu *vcpu, void __user *argp)
> >  int tdx_gmem_private_max_mapping_level(struct kvm_vcpu *vcpu, kvm_pfn_t pfn,
> >                                        gfn_t gfn, bool prefetch)
> >  {
> > -       struct vcpu_tdx *tdx = to_tdx(vcpu);
> > -
> > -       if (unlikely((to_kvm_tdx(vcpu->kvm)->state != TD_STATE_RUNNABLE) || prefetch))
> > +       if (unlikely((to_kvm_tdx(vcpu->kvm)->state != TD_STATE_RUNNABLE)))
> >                 return PG_LEVEL_4K;
> > 
> > -       if (gfn >= tdx->violation_gfn_start && gfn < tdx->violation_gfn_end)
> > -               return tdx->violation_request_level;
> > -
> >         return PG_LEVEL_2M;
> >  }
> > 
> > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > index acd18a01f63d..3a3077666ee6 100644
> > --- a/virt/kvm/kvm_main.c
> > +++ b/virt/kvm/kvm_main.c
> > @@ -2610,6 +2610,7 @@ struct kvm_memory_slot *kvm_vcpu_gfn_to_memslot(struct kvm_vcpu *vcpu, gfn_t gfn
> > 
> >         return NULL;
> >  }
> > +EXPORT_SYMBOL_GPL(kvm_vcpu_gfn_to_memslot);
> > 
> >  bool kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn)
> >  {
> 

  reply	other threads:[~2025-07-01  2:45 UTC|newest]

Thread overview: 294+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-24  3:00 [RFC PATCH 00/21] KVM: TDX huge page support for private memory Yan Zhao
2025-04-24  3:04 ` [RFC PATCH 01/21] KVM: gmem: Allocate 2M huge page from guest_memfd backend Yan Zhao
2025-04-24  3:04 ` [RFC PATCH 02/21] x86/virt/tdx: Enhance tdh_mem_page_aug() to support huge pages Yan Zhao
2025-04-24  7:48   ` Kirill A. Shutemov
2025-04-24  8:41     ` Yan Zhao
2025-04-25  6:51   ` Binbin Wu
2025-04-25  7:19     ` Yan Zhao
2025-05-13 18:52   ` Edgecombe, Rick P
2025-05-16  9:05     ` Yan Zhao
2025-05-16 17:10       ` Edgecombe, Rick P
2025-06-19  9:26       ` Nikolay Borisov
2025-06-23  9:32         ` Yan Zhao
2025-05-15  2:16   ` Chao Gao
2025-05-16  9:07     ` Yan Zhao
2025-07-08  8:48   ` Yan Zhao
2025-07-08 13:55     ` Edgecombe, Rick P
2025-07-08 15:29       ` Vishal Annapurve
2025-07-08 15:32         ` Edgecombe, Rick P
2025-07-08 22:06           ` Vishal Annapurve
2025-07-08 23:16             ` Edgecombe, Rick P
2025-07-08 23:31               ` Vishal Annapurve
2025-07-09  2:23       ` Yan Zhao
2025-07-09 14:08         ` Edgecombe, Rick P
2025-04-24  3:04 ` [RFC PATCH 03/21] x86/virt/tdx: Add SEAMCALL wrapper tdh_mem_page_demote() Yan Zhao
2025-04-25  7:12   ` Binbin Wu
2025-04-25  7:17     ` Yan Zhao
2025-04-25  7:25       ` Binbin Wu
2025-04-25  9:24         ` Yan Zhao
2025-05-13 18:19   ` Edgecombe, Rick P
2025-05-15  8:26     ` Yan Zhao
2025-05-15 17:28       ` Edgecombe, Rick P
2025-05-16  2:23         ` Yan Zhao
2025-07-01 21:15         ` Edgecombe, Rick P
2025-04-24  3:05 ` [RFC PATCH 04/21] KVM: TDX: Enforce 4KB mapping level during TD build Time Yan Zhao
2025-04-24  7:55   ` Kirill A. Shutemov
2025-04-24  8:49     ` Yan Zhao
2025-05-13 19:12   ` Edgecombe, Rick P
2025-05-15  9:16     ` Yan Zhao
2025-05-15 17:32       ` Edgecombe, Rick P
2025-05-16 10:05         ` Yan Zhao
2025-04-24  3:05 ` [RFC PATCH 05/21] KVM: TDX: Enhance tdx_clear_page() to support huge pages Yan Zhao
2025-05-13 19:17   ` Edgecombe, Rick P
2025-05-16  2:02     ` Yan Zhao
2025-04-24  3:05 ` [RFC PATCH 06/21] KVM: TDX: Assert the reclaimed pages were mapped as expected Yan Zhao
2025-05-13 19:25   ` Edgecombe, Rick P
2025-05-16  2:11     ` Yan Zhao
2025-05-16 17:34       ` Edgecombe, Rick P
2025-04-24  3:05 ` [RFC PATCH 07/21] KVM: TDX: Add a helper for WBINVD on huge pages with TD's keyID Yan Zhao
2025-05-06  8:37   ` Binbin Wu
2025-05-16  3:10     ` Yan Zhao
2025-05-13 19:29   ` Edgecombe, Rick P
2025-05-16  3:03     ` Yan Zhao
2025-05-16 17:35       ` Edgecombe, Rick P
2025-04-24  3:06 ` [RFC PATCH 08/21] KVM: TDX: Increase/decrease folio ref for huge pages Yan Zhao
2025-04-29  0:17   ` Vishal Annapurve
2025-04-29  0:49     ` Yan Zhao
2025-04-29 13:46       ` Vishal Annapurve
2025-05-06  0:53         ` Yan Zhao
2025-05-06  5:08           ` Vishal Annapurve
2025-05-06  6:04             ` Yan Zhao
2025-05-06 13:18               ` Vishal Annapurve
2025-05-07  7:37                 ` Yan Zhao
2025-05-07 14:56                   ` Vishal Annapurve
2025-05-08  1:30                     ` Yan Zhao
2025-05-08 14:10                       ` Vishal Annapurve
2025-05-09  3:20                         ` Yan Zhao
2025-05-09 14:20                           ` Vishal Annapurve
2025-05-09 23:45                             ` Edgecombe, Rick P
2025-05-10  0:41                               ` Vishal Annapurve
2025-05-12 21:59                                 ` Edgecombe, Rick P
2025-05-12  2:15                             ` Yan Zhao
2025-05-12 16:53                               ` Vishal Annapurve
2025-05-15  3:01                                 ` Yan Zhao
2025-06-04 20:02                                   ` Ackerley Tng
2025-06-05  2:42                                     ` Yan Zhao
2025-06-05 21:12                                       ` Ackerley Tng
2025-06-16 10:43                                         ` Yan Zhao
2025-06-16 23:27                                           ` Edgecombe, Rick P
2025-06-11 14:30                                       ` Vishal Annapurve
2025-06-16  9:59                                         ` Yan Zhao
2025-06-17  0:12                                           ` Edgecombe, Rick P
2025-06-17  1:38                                             ` Yan Zhao
2025-06-17 15:52                                               ` Edgecombe, Rick P
2025-06-18  0:19                                                 ` Yan Zhao
2025-06-18  0:41                                                   ` Edgecombe, Rick P
2025-06-23  9:27                                                     ` Yan Zhao
2025-06-23 18:20                                                       ` Edgecombe, Rick P
     [not found]                                                       ` <draft-diqzh606mcz0.fsf@ackerleytng-ctop.c.googlers.com>
2025-06-23 22:48                                                         ` Ackerley Tng
2025-06-24 10:18                                                           ` Yan Zhao
2025-06-24 21:29                                                             ` Ackerley Tng
2025-06-24 22:22                                                               ` Edgecombe, Rick P
2025-06-24 22:00                                                           ` Edgecombe, Rick P
2025-06-24 22:14                                                             ` Edgecombe, Rick P
2025-06-24 23:30                                                             ` Ackerley Tng
2025-06-25  0:01                                                               ` Edgecombe, Rick P
2025-06-25  7:29                                                                 ` Yan Zhao
2025-06-25 23:09                                                                 ` Ackerley Tng
2025-06-25 23:19                                                                   ` Edgecombe, Rick P
2025-06-26 15:16                                                                     ` Shutemov, Kirill
2025-06-26 22:19                                                                       ` Edgecombe, Rick P
2025-06-27 17:59                                                                         ` Ackerley Tng
2025-06-30 11:13                                                                           ` Yan Zhao
2025-06-30 17:55                                                                             ` Edgecombe, Rick P
2025-06-30 19:25                                                                               ` Ackerley Tng
2025-06-30 21:45                                                                                 ` Edgecombe, Rick P
2025-07-01  5:01                                                                                   ` Yan Zhao
2025-07-01  5:22                                                                                     ` Vishal Annapurve
2025-07-01  6:03                                                                                       ` Yan Zhao
2025-07-01  7:13                                                                                         ` Vishal Annapurve
2025-07-01 14:15                                                                                           ` Edgecombe, Rick P
2025-07-01 22:09                                                                                         ` Ackerley Tng
2025-07-02 11:24                                                                                           ` Yan Zhao
2025-07-02 18:43                                                                                             ` Ackerley Tng
2025-07-03  4:54                                                                                               ` Yan Zhao
2025-07-14 19:32                                                                                                 ` Ackerley Tng
2025-07-01 16:13                                                                                     ` Edgecombe, Rick P
2025-07-01 21:48                                                                                       ` Ackerley Tng
2025-07-01 21:57                                                                                         ` Ackerley Tng
2025-07-01 22:37                                                                                         ` Edgecombe, Rick P
2025-07-02 20:57                                                                                           ` Ackerley Tng
2025-07-02 23:51                                                                                             ` Edgecombe, Rick P
2025-07-08 21:19                                                                                               ` Ackerley Tng
2025-07-11  1:46                                                                                                 ` Edgecombe, Rick P
2025-07-11  5:12                                                                                                   ` Yan Zhao
2025-07-11 16:14                                                                                                     ` Edgecombe, Rick P
2025-07-14 19:49                                                                                                       ` Ackerley Tng
2025-07-15 15:08                                                                                                         ` Edgecombe, Rick P
2025-07-15 22:31                                                                                                           ` Ackerley Tng
2025-07-02  9:08                                                                                       ` Yan Zhao
2025-07-02 15:28                                                                                         ` Edgecombe, Rick P
2025-07-01  5:07                                                                                 ` Yan Zhao
2025-07-01 22:01                                                                                   ` Ackerley Tng
2025-07-01 22:26                                                                                     ` Ackerley Tng
2025-06-30 21:47                                                                               ` Vishal Annapurve
2025-07-01  9:35                                                                               ` Yan Zhao
2025-07-01 13:32                                                                                 ` Vishal Annapurve
2025-07-01 14:02                                                                                   ` Vishal Annapurve
2025-07-01 15:42                                                                                     ` Edgecombe, Rick P
2025-07-01 16:14                                                                                   ` Edgecombe, Rick P
2025-07-02  8:54                                                                                   ` Yan Zhao
2025-07-02 13:12                                                                                     ` Vishal Annapurve
2025-06-25  7:08                                                               ` Yan Zhao
2025-06-25 22:54                                                                 ` Ackerley Tng
2025-06-24 22:03                                                           ` Edgecombe, Rick P
2025-06-17  0:25                                           ` Edgecombe, Rick P
2025-06-17  2:00                                             ` Yan Zhao
2025-06-17  3:51                                           ` Vishal Annapurve
2025-06-17  6:52                                             ` Yan Zhao
2025-06-17  8:09                                               ` Vishal Annapurve
2025-06-17  9:57                                                 ` Yan Zhao
2025-06-18  4:25                                                   ` Vishal Annapurve
2025-06-18  0:34                                                 ` Edgecombe, Rick P
2025-06-18  0:46                                                   ` Yan Zhao
2025-06-18  4:33                                                     ` Vishal Annapurve
2025-06-18  6:13                                                       ` Yan Zhao
2025-06-18  6:21                                                         ` Vishal Annapurve
2025-06-18  6:32                                                           ` Yan Zhao
2025-06-18  6:44                                                             ` Vishal Annapurve
2025-06-18  6:57                                                               ` Yan Zhao
2025-06-18  4:29                                                   ` Vishal Annapurve
2025-06-19  0:22                                                     ` Edgecombe, Rick P
2025-06-05  2:47                                     ` Yan Zhao
2025-06-05 22:35                                       ` Ackerley Tng
2025-06-19  8:11                                         ` Yan Zhao
2025-06-20 18:06                                           ` Vishal Annapurve
2025-07-16  1:23                                         ` Yan Zhao
2025-07-16 20:57                                           ` Ackerley Tng
2025-07-18  5:49                                             ` Yan Zhao
2025-07-22  5:33                                               ` Ackerley Tng
2025-07-22  6:37                                                 ` Yan Zhao
2025-07-22 17:55                                                   ` Ackerley Tng
2025-05-12 19:00                           ` Ackerley Tng
2025-05-12 21:44                             ` Edgecombe, Rick P
2025-04-24  3:06 ` [RFC PATCH 09/21] KVM: TDX: Enable 2MB mapping size after TD is RUNNABLE Yan Zhao
2025-05-13 20:10   ` Edgecombe, Rick P
2025-05-16  1:35     ` Huang, Kai
2025-05-16  9:43       ` Yan Zhao
2025-05-16 22:35         ` Huang, Kai
2025-05-16 23:47           ` Edgecombe, Rick P
2025-05-19  8:32           ` Yan Zhao
2025-05-19 16:53             ` Edgecombe, Rick P
2025-05-20  9:34               ` Yan Zhao
2025-05-20 23:47                 ` Huang, Kai
2025-06-11 14:42                   ` Sean Christopherson
2025-06-12 23:39                     ` Edgecombe, Rick P
2025-06-13  0:19                       ` Sean Christopherson
2025-06-13  0:25                         ` Edgecombe, Rick P
2025-06-13  0:44                           ` Sean Christopherson
2025-06-13  0:47                             ` Edgecombe, Rick P
2025-06-13  1:32                               ` Yan Zhao
2025-06-13 21:53                                 ` Edgecombe, Rick P
2025-06-13 22:19                                   ` Sean Christopherson
2025-06-13 23:33                                     ` Edgecombe, Rick P
2025-06-16  3:14                                       ` Yan Zhao
2025-06-16 22:49                                         ` Edgecombe, Rick P
2025-06-17  0:52                                           ` Yan Zhao
2025-06-18  0:30                                             ` Yan Zhao
2025-06-20 16:31                                               ` Sean Christopherson
2025-06-23 21:44                                                 ` Edgecombe, Rick P
2025-06-24  9:57                                                   ` Yan Zhao
2025-06-24 18:35                                                     ` Edgecombe, Rick P
2025-06-25  9:28                                                       ` Yan Zhao
2025-06-25  9:36                                                         ` Yan Zhao
2025-06-25 14:48                                                           ` Edgecombe, Rick P
2025-06-26  0:50                                                             ` Yan Zhao
2025-06-25 14:47                                                         ` Edgecombe, Rick P
2025-06-26  8:53                                                           ` Yan Zhao
2025-07-01  0:42                                                             ` Edgecombe, Rick P
2025-07-01  2:41                                                               ` Yan Zhao [this message]
2025-07-01 15:36                                                                 ` Edgecombe, Rick P
2025-07-02  0:12                                                                   ` Yan Zhao
2025-07-02  0:18                                                                     ` Edgecombe, Rick P
2025-07-02  1:07                                                                       ` Yan Zhao
2025-07-02 15:26                                                                         ` Edgecombe, Rick P
2025-07-02  3:31                                                                       ` Yan Zhao
2025-06-25 13:47                                                       ` Vishal Annapurve
2025-06-25 15:51                                                         ` Edgecombe, Rick P
2025-06-18  1:22                                             ` Edgecombe, Rick P
2025-06-18 11:32                                               ` Shutemov, Kirill
2025-06-20 16:32                                                 ` Sean Christopherson
2025-06-20 17:44                                                   ` Kirill Shutemov
2025-06-20 18:40                                                     ` Sean Christopherson
2025-06-20 19:26                                                       ` Kirill Shutemov
2025-06-13  2:41                     ` Xiaoyao Li
2025-06-13  3:29                       ` Yan Zhao
2025-06-13  5:35                         ` Yan Zhao
2025-06-13  6:08                           ` Xiaoyao Li
2025-05-21 15:40                 ` Edgecombe, Rick P
2025-05-22  3:52                   ` Yan Zhao
2025-05-23 23:40                     ` Edgecombe, Rick P
2025-05-27  1:31                       ` Yan Zhao
2025-05-20 23:34             ` Huang, Kai
2025-05-21  2:35               ` Yan Zhao
2025-05-16  9:28     ` Yan Zhao
2025-04-24  3:06 ` [RFC PATCH 10/21] KVM: x86/mmu: Disallow page merging (huge page adjustment) for mirror root Yan Zhao
2025-05-13 20:15   ` Edgecombe, Rick P
2025-05-16  4:01     ` Yan Zhao
2025-05-16 17:50       ` Edgecombe, Rick P
2025-05-19  3:57         ` Yan Zhao
2025-05-19 17:42           ` Edgecombe, Rick P
2025-05-20 10:11             ` Yan Zhao
2025-04-24  3:06 ` [RFC PATCH 11/21] KVM: x86: Add "vcpu" "gfn" parameters to x86 hook private_max_mapping_level Yan Zhao
2025-04-24  3:07 ` [RFC PATCH 12/21] KVM: TDX: Determine max mapping level according to vCPU's ACCEPT level Yan Zhao
2025-05-13 21:20   ` Edgecombe, Rick P
2025-05-16  6:12     ` Xiaoyao Li
2025-05-16  6:30     ` Yan Zhao
2025-05-16 22:02       ` Edgecombe, Rick P
2025-05-19  6:39         ` Yan Zhao
2025-05-19 20:17           ` Edgecombe, Rick P
2025-04-24  3:07 ` [RFC PATCH 13/21] KVM: x86/tdp_mmu: Alloc external_spt page for mirror page table splitting Yan Zhao
2025-04-24  3:07 ` [RFC PATCH 14/21] KVM: x86/tdp_mmu: Invoke split_external_spt hook with exclusive mmu_lock Yan Zhao
2025-05-13 23:06   ` Edgecombe, Rick P
2025-05-16  9:17     ` Yan Zhao
2025-05-16 22:11       ` Edgecombe, Rick P
2025-05-19  4:01         ` Yan Zhao
2025-05-19 20:21           ` Edgecombe, Rick P
2025-05-20  5:40   ` Binbin Wu
2025-05-20  9:40     ` Yan Zhao
2025-04-24  3:08 ` [RFC PATCH 15/21] KVM: TDX: Support huge page splitting with exclusive kvm->mmu_lock Yan Zhao
2025-05-20  6:18   ` Binbin Wu
2025-05-20  9:40     ` Yan Zhao
2025-07-02 15:47   ` Edgecombe, Rick P
2025-04-24  3:08 ` [RFC PATCH 16/21] KVM: x86/mmu: Introduce kvm_split_boundary_leafs() to split boundary leafs Yan Zhao
2025-05-13 22:56   ` Edgecombe, Rick P
2025-05-16  7:46     ` Yan Zhao
2025-05-16  8:03       ` Yan Zhao
2025-05-16 22:27         ` Edgecombe, Rick P
2025-05-19  8:12           ` Yan Zhao
2025-05-16 11:44       ` Yan Zhao
2025-05-16 22:16         ` Edgecombe, Rick P
2025-04-24  3:08 ` [RFC PATCH 17/21] KVM: Change the return type of gfn_handler_t() from bool to int Yan Zhao
2025-04-24  3:08 ` [RFC PATCH 18/21] KVM: x86: Split huge boundary leafs before private to shared conversion Yan Zhao
2025-05-09 23:34   ` Edgecombe, Rick P
2025-05-12  2:25     ` Yan Zhao
2025-05-12 21:53       ` Edgecombe, Rick P
2025-04-24  3:08 ` [RFC PATCH 19/21] KVM: gmem: Split huge boundary leafs for punch hole of private memory Yan Zhao
2025-04-24 10:19   ` Francesco Lavra
2025-04-25  1:55     ` Yan Zhao
2025-05-13 22:59   ` Edgecombe, Rick P
2025-05-16  8:19     ` Yan Zhao
2025-04-24  3:09 ` [RFC PATCH 20/21] KVM: x86: Force a prefetch fault's max mapping level to 4KB for TDX Yan Zhao
2025-05-13 23:20   ` Edgecombe, Rick P
2025-05-16  8:43     ` Yan Zhao
2025-05-21  3:30   ` Binbin Wu
2025-05-21  5:03     ` Yan Zhao
2025-04-24  3:09 ` [RFC PATCH 21/21] KVM: x86: Ignore splitting huge pages in fault path " Yan Zhao
2025-05-13 21:58   ` Edgecombe, Rick P
2025-05-16  6:40     ` Yan Zhao
2025-04-24  7:35 ` [RFC PATCH 00/21] KVM: TDX huge page support for private memory Kirill A. Shutemov
2025-04-24  8:33   ` Yan Zhao
2025-04-24  9:05     ` Kirill A. Shutemov
2025-04-24  9:08       ` Juergen Gross
2025-04-24  9:49       ` Yan Zhao
2025-04-24 10:39         ` Kirill A. Shutemov

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=aGNK2tO2W6+GWtt3@yzhao56-desk.sh.intel.com \
    --to=yan.y.zhao@intel.com \
    --cc=ackerleytng@google.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=chao.p.peng@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=fan.du@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=isaku.yamahata@intel.com \
    --cc=jroedel@suse.de \
    --cc=jun.miao@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kirill.shutemov@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=pbonzini@redhat.com \
    --cc=pgonda@google.com \
    --cc=quic_eberman@quicinc.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=seanjc@google.com \
    --cc=tabba@google.com \
    --cc=thomas.lendacky@amd.com \
    --cc=vannapurve@google.com \
    --cc=vbabka@suse.cz \
    --cc=x86@kernel.org \
    --cc=xiaoyao.li@intel.com \
    --cc=zhiquan1.li@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 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.