mirror of https://lore.kernel.org/lkml/
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®