* Re: [RFC PATCH v5 16/45] x86/virt/tdx: Add tdx_alloc/free_control_page() helpers
From: Sean Christopherson @ 2026-02-05 22:35 UTC (permalink / raw)
To: Yan Zhao
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Paolo Bonzini, linux-kernel, linux-coco, kvm,
Kai Huang, Rick Edgecombe, Vishal Annapurve, Ackerley Tng,
Sagi Shahar, Binbin Wu, Xiaoyao Li, Isaku Yamahata
In-Reply-To: <aYQ0l+C42gssMHHV@yzhao56-desk.sh.intel.com>
On Thu, Feb 05, 2026, Yan Zhao wrote:
> > diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> > index f6e80aba5895..682c8a228b53 100644
> > --- a/arch/x86/virt/vmx/tdx/tdx.c
> > +++ b/arch/x86/virt/vmx/tdx/tdx.c
> > @@ -1824,6 +1824,50 @@ u64 tdh_mng_rd(struct tdx_td *td, u64 field, u64 *data)
> > }
> > EXPORT_SYMBOL_FOR_KVM(tdh_mng_rd);
> >
> > +/* Number PAMT pages to be provided to TDX module per 2M region of PA */
> > +static int tdx_dpamt_entry_pages(void)
> > +{
> > + if (!tdx_supports_dynamic_pamt(&tdx_sysinfo))
> > + return 0;
> > +
> This function is not invoked when !tdx_supports_dynamic_pamt().
> So, probably we can just return the count below?
Or maybe WARN_ON_ONCE() and return 0? I have no strong preference.
> > + return tdx_sysinfo.tdmr.pamt_4k_entry_size * PTRS_PER_PTE / PAGE_SIZE;
> > +}
> > +
>
^ permalink raw reply
* Re: [RFC PATCH v5 08/45] KVM: x86/mmu: Propagate mirror SPTE removal to S-EPT in handle_changed_spte()
From: Sean Christopherson @ 2026-02-05 22:33 UTC (permalink / raw)
To: Yan Zhao
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Paolo Bonzini, linux-kernel, linux-coco, kvm,
Kai Huang, Rick Edgecombe, Vishal Annapurve, Ackerley Tng,
Sagi Shahar, Binbin Wu, Xiaoyao Li, Isaku Yamahata
In-Reply-To: <aYQtIK/Lq5T3ad6V@yzhao56-desk.sh.intel.com>
On Thu, Feb 05, 2026, Yan Zhao wrote:
> On Wed, Feb 04, 2026 at 06:23:38PM -0800, Sean Christopherson wrote:
> > On Wed, Feb 04, 2026, Yan Zhao wrote:
> > > On Wed, Jan 28, 2026 at 05:14:40PM -0800, Sean Christopherson wrote:
> > > > @@ -590,10 +566,21 @@ static void handle_changed_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
> > > > * the paging structure. Note the WARN on the PFN changing without the
> > > > * SPTE being converted to a hugepage (leaf) or being zapped. Shadow
> > > > * pages are kernel allocations and should never be migrated.
> > > > + *
> > > > + * When removing leaf entries from a mirror, immediately propagate the
> > > > + * changes to the external page tables. Note, non-leaf mirror entries
> > > > + * are handled by handle_removed_pt(), as TDX requires that all leaf
> > > > + * entries are removed before the owning page table. Note #2, writes
> > > > + * to make mirror PTEs shadow-present are propagated to external page
> > > > + * tables by __tdp_mmu_set_spte_atomic(), as KVM needs to ensure the
> > > > + * external page table was successfully updated before marking the
> > > > + * mirror SPTE present.
> > > > */
> > > > if (was_present && !was_leaf &&
> > > > (is_leaf || !is_present || WARN_ON_ONCE(pfn_changed)))
> > > > handle_removed_pt(kvm, spte_to_child_pt(old_spte, level), shared);
> > > > + else if (was_leaf && is_mirror_sptep(sptep) && !is_leaf)
> > > Should we check !is_present instead of !is_leaf?
> > > e.g. a transition from a present leaf entry to a present non-leaf entry could
> > > also trigger this if case.
> >
> > No, the !is_leaf check is very intentional. At this point in the series, S-EPT
> > doesn't support hugepages. If KVM manages to install a leaf SPTE and replaces
> > that SPTE with a non-leaf SPTE, then we absolutely want the KVM_BUG_ON() in
> > tdx_sept_remove_private_spte() to fire:
> >
> > /* TODO: handle large pages. */
> > if (KVM_BUG_ON(level != PG_LEVEL_4K, kvm))
> > return -EIO;
> But the op is named remove_external_spte().
> And the check of "level != PG_LEVEL_4K" is for removing large leaf entries.
I agree that the naming at this point in the series is unfortunate, but I don't
see it as outright wrong. That the TDP MMU could theoretically replace the leaf
SPTE with a non-leaf SPTE doesn't change the fact that the old leaf SPTE *is*
being removed.
> Relying on this check is tricky and confusing.
If it's still confusing at the end of the series, then I'm happy to discuss how
we can make it less confusion. But as of this point in the series, I unfortunately
don't see a better way to achieve my end goals (reducing the number of kvm_x86_ops
hooks, and reducing how many TDX specific details bleed into common MMU code).
There are "different" ways to incrementally move from where were at today, to where
I want KVM to be, but I don't see them as "better". I.e. AFAICT, there's no way
to move incrementally with reviewable patches while also maintaining perfect/ideal
naming and flow.
> > And then later on, when S-EPT gains support for hugepages, "KVM: TDX: Add core
> > support for splitting/demoting 2MiB S-EPT to 4KiB" doesn't need to touch code
> > outside of arch/x86/kvm/vmx/tdx.c, because everything has already been plumbed
> > in.
> I haven't looked at the later patches for huge pages,
Please do. As above, I don't think it's realistic to completely avoid some amount
of "eww" in the intermediate stages.
> but plumbing here directly for splitting does not look right when it's
> invoked under shared mmu_lock.
> See the comment below.
>
> > > Besides, need "KVM_BUG_ON(shared, kvm)" in this case.
> >
> > Eh, we have lockdep_assert_held_write() in the S-EPT paths that require mmu_lock
> > to be held for write. I don't think a KVM_BUG_ON() here would add meaningful
> > value.
> Hmm, I think KVM_BUG_ON(shared, kvm) is still useful.
> If KVM invokes remove_external_spte() under shared mmu_lock, it needs to freeze
> the entry first, similar to the sequence in __tdp_mmu_set_spte_atomic().
>
> i.e., invoking external x86 ops in handle_changed_spte() for mirror roots should
> be !shared only.
Sure, but...
> Relying on the TDX code's lockdep_assert_held_write() for warning seems less
> clear than having an explicit check here.
...that's TDX's responsibility to enforce, and I don't see any justification for
something more than a lockdep assertion. As I've said elsewhere, several times,
at some point we have to commit to getting the code right. Adding KVM_BUG_ON() in
Every. Single. Call. does not yield more maintainable code. There are myriad
things KVM can screw up, many of which have far, far more harmful impact than
calling an S-EPT hook with mmu_lock held for read instead of write.
The bar for adding a KVM_BUG_ON() is not simply "this shouldn't happen". It's,
this shouldn't happen *and* at least one of (not a complete list):
- we've either screwed this up badly more than once
- it's really hard to get right
- we might not notice if we do screw it up
- KVM might corrupt data if we continue on
^ permalink raw reply
* Re: [PATCH v2 0/2] x86/virt/tdx: Print TDX module version to dmesg
From: Verma, Vishal L @ 2026-02-05 19:05 UTC (permalink / raw)
To: kvm@vger.kernel.org, linux-coco@lists.linux.dev,
linux-kernel@vger.kernel.org
Cc: Gao, Chao, Edgecombe, Rick P, dave.hansen@linux.intel.com,
Huang, Kai, kas@kernel.org, bp@alien8.de, mingo@redhat.com,
Williams, Dan J, tglx@linutronix.de, hpa@zytor.com,
x86@kernel.org
In-Reply-To: <20260109-tdx_print_module_version-v2-0-e10e4ca5b450@intel.com>
On Fri, 2026-01-09 at 12:14 -0700, Vishal Verma wrote:
> === Problem & Solution ===
>
> Currently, there is neither an ABI, nor any other way to determine from
> the host system, what version of the TDX module is running. A sysfs ABI
> for this has been proposed in [1], but it may need additional discussion.
>
> Many/most TDX developers already carry patches like this in their
> development branches. It can be tricky to know which TDX module is
> actually loaded on a system, and so this functionality has been needed
> regularly for development and processing bug reports. Hence, it is
> prudent to break out the patches to retrieve and print the TDX module
> version, as those parts are very straightforward, and get some level of
> debugability and traceability for TDX host systems.
>
> === Dependencies ===
>
> None. This is based on v6.19-rc4, and applies cleanly to tip.git.
>
> === Patch details ===
>
> Patch 1 is a prerequisite that adds the infrastructure to retrieve the
> TDX module version from its global metadata. This was originally posted in [2].
>
> Patch 2 is based on a patch from Kai Huang [3], and prints the version to
> dmesg during init.
>
> === Testing ===
>
> This has passed the usual suite of tests, including successful 0day
> builds, KVM Unit tests, KVM selftests, a TD creation smoke test, and
> selected KVM tests from the Avocado test suite.
>
> [1]: https://lore.kernel.org/all/20260105074350.98564-1-chao.gao@intel.com/
> [2]: https://lore.kernel.org/all/20260105074350.98564-2-chao.gao@intel.com/
> [3]: https://lore.kernel.org/all/57eaa1b17429315f8b5207774307f3c1dd40cf37.1730118186.git.kai.huang@intel.com/
>
> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Hi Kiryl, just wanted to check on the plan for this, I didn't see it
merged in tip.git x86/tdx (or any other tip branch). Were you planning
to take it through x86/tdx? Can I help with anything to move it along?
Thank you,
Vishal
^ permalink raw reply
* Re: [PATCH v4 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: David Hildenbrand (Arm) @ 2026-02-05 17:29 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Pratik R. Sampat, linux-mm, linux-coco, x86, linux-kernel, tglx,
mingo, bp, dave.hansen, ardb, akpm, osalvador, thomas.lendacky,
michael.roth
In-Reply-To: <aYS8O0phOE41IuEF@thinkstation>
On 2/5/26 17:08, Kiryl Shutsemau wrote:
> On Thu, Feb 05, 2026 at 04:48:13PM +0100, David Hildenbrand (Arm) wrote:
>> On 2/5/26 11:48, Kiryl Shutsemau wrote:
>>>
>>> You are calling arch_accept_memory() on every memory allocation if the
>>> memory is not represented in the bitmap. Hard NAK.
>>
>> In which scenarios would we not have memory represented in the bitmap?
>> Guests with <4 GiB? (how does kexec work?) Anything else?
>
> We create the bitmap that covers all unaccepted memory.
Good! :)
>
> What memory is unaccepted is up to BIOS. Current implementation of edk2
> accepts the memory in the first 4G range of physical address space. It
> means we won't have bitmap for this range (unaccepted->phys_base >= 4G).
Ah, okay, this comes from the BIOS.
>
> If the whole VM is smaller than 4G we won't have the bitmap at all.
>
> We can allocate bitmap for all possible memory. Maybe upto max_possible_pfn?
> But we might not know the value in EFI stub. It costs 4k per 64GiB of
> physical address space.
That's what I would do. 4k per 64GiB sounds reasonable.
>
> Ideally, we want to know on boot:
>
> - what memory ranges are unaccepted - we have it;
> - what memory range can be removed or added after boot - we don't have it
The SRAT describes memory ranges where we can see hotplug memory. Is
that too late? We calculate max_possible_pfn based on that.
(don't ask me about special CXL windows and how they are advertised :) )
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v3 07/26] x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs
From: Dave Hansen @ 2026-02-05 16:37 UTC (permalink / raw)
To: Sean Christopherson, Chao Gao
Cc: linux-coco, linux-kernel, kvm, x86, reinette.chatre, ira.weiny,
kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve, paulmck,
nik.borisov, zhenzhong.duan, rick.p.edgecombe, kas, dave.hansen,
vishal.l.verma, Farrah Chen, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin
In-Reply-To: <aYTFZv9Mf_FqWM_k@google.com>
On 2/5/26 08:29, Sean Christopherson wrote:
> No, this isn't the explanation. I found the explanation in the pseudocode for
> SEAMRET. The "successful VM-Entry" path says this:
>
> current-VMCS = current-VMCS.VMCS-link-pointer
> IF inP_SEAMLDR == 1; THEN
> If current-VMCS != FFFFFFFF_FFFFFFFFH; THEN
> Ensure data for VMCS referenced by current-VMC is in memory
> Initialize implementation-specific data in all VMCS referenced by current-VMCS
> Set launch state of VMCS referenced by current-VMCS to “clear”
> current-VMCS = FFFFFFFF_FFFFFFFFH
> FI;
> inP_SEAMLDR = 0
> FI;
Yes, in version 002 of the spec. It wasn't there in 001.
The basic problem is that the SEAM VMCSes need to get flushed when the
TDX module is being loaded. The TDX module never loads itself, thus the
"inP_SEAMLDR == 1" check. It sounds like there was already an existing
thing in microcode to just flush VMCSes and invalidate "current-VMCS".
It was much easier for microcode to just jump over to that existing
thing than to surgically target the SEAM VMCSes, or somehow avoid
zapping "current-VMCS". It makes total sense for the microcoders to have
gone this route.
I'm seeing if it can get changed back to the 001 version so we just
don't even have to deal with this whole mess.
^ permalink raw reply
* Re: [PATCH v3 07/26] x86/virt/seamldr: Introduce a wrapper for P-SEAMLDR SEAMCALLs
From: Sean Christopherson @ 2026-02-05 16:29 UTC (permalink / raw)
To: Chao Gao
Cc: Dave Hansen, linux-coco, linux-kernel, kvm, x86, reinette.chatre,
ira.weiny, kai.huang, dan.j.williams, yilun.xu, sagis, vannapurve,
paulmck, nik.borisov, zhenzhong.duan, rick.p.edgecombe, kas,
dave.hansen, vishal.l.verma, Farrah Chen, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <aYKKnf7K3lRdUcxl@intel.com>
On Wed, Feb 04, 2026, Chao Gao wrote:
> >On Fri, Jan 30, 2026 at 8:23 AM Dave Hansen <dave.hansen@intel.com> wrote:
> >> On 1/30/26 00:08, Chao Gao wrote:
> >> > AFAIK, this is a CPU implementation issue. The actual requirement is to
> >> > evict (flush and invalidate) all VMCSs __cached in SEAM mode__, but big
> >> > cores implement this by evicting the __entire__ VMCS cache. So, the
> >> > current VMCS is invalidated and cleared.
> >>
> >> But why is this a P-SEAMLDR thing and not a TDX module thing?
> >
> >My guess is that it's because the P-SEAMLDR code loads and prepares the new TDX-
> >Module by constructing the VMCS used for SEAMCALL using direct writes to memory
> >(unless that TDX behavior has changed in the last few years). And so it needs
> >to ensure that in-memory representation is synchronized with the VMCS cache.
> >
> >Hmm, but that doesn't make sense _if_ it really truly is SEAMRET that does the VMCS
> >cache invalidation, because flushing the VMCS cache would ovewrite the in-memory
> >state.
>
> My understanding is:
>
> 1. SEAMCALL/SEAMRET use VMCSs.
>
> 2. P-SEAMLDR is single-threaded (likely for simplicity). So, it uses a _single_
> global VMCS and only one CPU can call P-SEAMLDR calls at a time.
>
> 3. After SEAMRET from P-SEAMLDR, _if_ the global VMCS isn't flushed, other CPUs
> cannot enter P-SEAMLDR because the global VMCS would be corrupted. (note the
> global VMCS is cached by the original CPU).
>
> 4. To make P-SEAMLDR callable on all CPUs, SEAMRET instruction flush VMCSs.
> The flush cannot be performed by the host VMM since the global VMCS is not
> visible to it. P-SEAMLDR cannot do it either because SEAMRET is its final
> instruction and requires a valid VMCS.
No, this isn't the explanation. I found the explanation in the pseudocode for
SEAMRET. The "successful VM-Entry" path says this:
current-VMCS = current-VMCS.VMCS-link-pointer
IF inP_SEAMLDR == 1; THEN
If current-VMCS != FFFFFFFF_FFFFFFFFH; THEN
Ensure data for VMCS referenced by current-VMC is in memory
Initialize implementation-specific data in all VMCS referenced by current-VMCS
Set launch state of VMCS referenced by current-VMCS to “clear”
current-VMCS = FFFFFFFF_FFFFFFFFH
FI;
inP_SEAMLDR = 0
FI;
I.e. my guess about firmware (probably XuCode?) doing direct writes was correct,
I just guessed wrong on which VMCS. Or rather, I didn't guess "all".
> The TDX Module has per-CPU VMCSs, so it doesn't has this problem.
>
> I'll check if SEAM ISA architects can join to explain this in more detail.
^ permalink raw reply
* Re: [PATCH v4 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: Kiryl Shutsemau @ 2026-02-05 16:08 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Pratik R. Sampat, linux-mm, linux-coco, x86, linux-kernel, tglx,
mingo, bp, dave.hansen, ardb, akpm, osalvador, thomas.lendacky,
michael.roth
In-Reply-To: <ce4334f8-5e54-4dbf-9be0-059279ef1962@kernel.org>
On Thu, Feb 05, 2026 at 04:48:13PM +0100, David Hildenbrand (Arm) wrote:
> On 2/5/26 11:48, Kiryl Shutsemau wrote:
> > On Wed, Feb 04, 2026 at 09:50:09PM -0600, Pratik R. Sampat wrote:
> > >
> > >
> > > On 2/4/26 2:00 PM, David Hildenbrand (arm) wrote:
> > > >
> > > > I really hate that accepting (and un-accepting) hotplugged memory is different to accepting ordinary boot memory.
> > > >
> > > > Is there really no way we can get a reasonable implementation where we just call a generic accept_memory() and it will know what to do?
> > > >
> > >
> > > Sure, that shouldn't be impossible.
> > >
> > > The only reason I initially kept them separate is because we accept and update
> > > the bitmap unconditionally. This mainly applies to cold-plugged memory since
> > > their bitmap state after remove shouldn't matter. However, as we are now
> > > correctly setting the bits in the hot-remove path we should be fine accepting
> > > from the for_each_set_bitrange_from() logic within accept_memory(), I think.
> > >
> > > Something like so?
> > >
> > > diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c
> > > index d11e7836200a..e56adfd382f8 100644
> > > --- a/drivers/firmware/efi/unaccepted_memory.c
> > > +++ b/drivers/firmware/efi/unaccepted_memory.c
> > > @@ -36,6 +36,7 @@ void accept_memory(phys_addr_t start, unsigned long size)
> > > unsigned long range_start, range_end;
> > > struct accept_range range, *entry;
> > > phys_addr_t end = start + size;
> > > + phys_addr_t bitmap_end;
> > > unsigned long flags;
> > > u64 unit_size;
> > >
> > > @@ -44,6 +45,21 @@ void accept_memory(phys_addr_t start, unsigned long size)
> > > return;
> > >
> > > unit_size = unaccepted->unit_size;
> > > + bitmap_end = unaccepted->phys_base + unaccepted->size * unit_size * BITS_PER_BYTE;
> > > +
> > > + /* Memory completely beyond bitmap: hotplug memory, accept unconditionally */
> > > + if (start >= bitmap_end) {
> > > + arch_accept_memory(start, end);
> > > + return;
> > > + }
> > > +
> > > + /* Memory partially beyond bitmap */
> > > + if (end > bitmap_end) {
> > > + arch_accept_memory(bitmap_end, end);
> > > + end = bitmap_end;
> > > + }
> >
> > You are calling arch_accept_memory() on every memory allocation if the
> > memory is not represented in the bitmap. Hard NAK.
>
> In which scenarios would we not have memory represented in the bitmap?
> Guests with <4 GiB? (how does kexec work?) Anything else?
We create the bitmap that covers all unaccepted memory.
What memory is unaccepted is up to BIOS. Current implementation of edk2
accepts the memory in the first 4G range of physical address space. It
means we won't have bitmap for this range (unaccepted->phys_base >= 4G).
If the whole VM is smaller than 4G we won't have the bitmap at all.
We can allocate bitmap for all possible memory. Maybe upto max_possible_pfn?
But we might not know the value in EFI stub. It costs 4k per 64GiB of
physical address space.
Ideally, we want to know on boot:
- what memory ranges are unaccepted - we have it;
- what memory range can be removed or added after boot - we don't have it
Then we can allocate bitmap that covers all this memory.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [RFC PATCH v5 00/45] TDX: Dynamic PAMT + S-EPT Hugepage
From: Dave Hansen @ 2026-02-05 16:01 UTC (permalink / raw)
To: Sean Christopherson
Cc: Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Kiryl Shutsemau, Paolo Bonzini,
linux-kernel, linux-coco, kvm, Kai Huang, Rick Edgecombe,
Yan Zhao, Vishal Annapurve, Ackerley Tng, Sagi Shahar, Binbin Wu,
Xiaoyao Li, Isaku Yamahata
In-Reply-To: <aYS85EsXu_xuQXSI@google.com>
On 2/5/26 07:53, Sean Christopherson wrote:
> I'm a-ok starting with a topic branch. If maintaining that branch becomes too
> costly, then we can always revisit things. And that would probably be good
> motiviation to beat guest_memfd hugepage into shape 🙂
Sounds like a plan.
^ permalink raw reply
* Re: [RFC PATCH v5 00/45] TDX: Dynamic PAMT + S-EPT Hugepage
From: Sean Christopherson @ 2026-02-05 15:53 UTC (permalink / raw)
To: Dave Hansen
Cc: Konrad Rzeszutek Wilk, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Kiryl Shutsemau, Paolo Bonzini,
linux-kernel, linux-coco, kvm, Kai Huang, Rick Edgecombe,
Yan Zhao, Vishal Annapurve, Ackerley Tng, Sagi Shahar, Binbin Wu,
Xiaoyao Li, Isaku Yamahata
In-Reply-To: <e60e0929-f3b0-463d-8c82-dc9170e401eb@intel.com>
On Wed, Feb 04, 2026, Dave Hansen wrote:
> On 2/4/26 06:38, Sean Christopherson wrote:
> ...
> > We can and do have tests and VMM support, but it's all out-of-tree (for now).
> > All I'm saying here is that I'm ok landing the S-EPT hugepage code in advance of
> > guest_memfd hugepage support, e.g. so that we don't end up in a stalemate due to
> > cyclical dependecies, or one big megaseries.
>
> Does "landing" mean having it sit in some topic branch, or pushing to Linus?
I was thinking pushing to Linus' tree, but a topic branch could likely provide
almost as much value?
> I'm all for getting these hellish dependency chains out of the way, but
> we usually try pretty hard to avoid having dead/unreachable code in
> mainline.
>
> If it is something you want to do in mainline, we should probably do a
> bit of cross-x86/kvm brainstorming to make sure there's no other option.
I'm a-ok starting with a topic branch. If maintaining that branch becomes too
costly, then we can always revisit things. And that would probably be good
motiviation to beat guest_memfd hugepage into shape :-)
^ permalink raw reply
* Re: [PATCH v4 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: David Hildenbrand (Arm) @ 2026-02-05 15:48 UTC (permalink / raw)
To: Kiryl Shutsemau, Pratik R. Sampat
Cc: linux-mm, linux-coco, x86, linux-kernel, tglx, mingo, bp,
dave.hansen, ardb, akpm, osalvador, thomas.lendacky, michael.roth
In-Reply-To: <aYR0vqwyFPo3EKAi@thinkstation>
On 2/5/26 11:48, Kiryl Shutsemau wrote:
> On Wed, Feb 04, 2026 at 09:50:09PM -0600, Pratik R. Sampat wrote:
>>
>>
>> On 2/4/26 2:00 PM, David Hildenbrand (arm) wrote:
>>>
>>> I really hate that accepting (and un-accepting) hotplugged memory is different to accepting ordinary boot memory.
>>>
>>> Is there really no way we can get a reasonable implementation where we just call a generic accept_memory() and it will know what to do?
>>>
>>
>> Sure, that shouldn't be impossible.
>>
>> The only reason I initially kept them separate is because we accept and update
>> the bitmap unconditionally. This mainly applies to cold-plugged memory since
>> their bitmap state after remove shouldn't matter. However, as we are now
>> correctly setting the bits in the hot-remove path we should be fine accepting
>> from the for_each_set_bitrange_from() logic within accept_memory(), I think.
>>
>> Something like so?
>>
>> diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c
>> index d11e7836200a..e56adfd382f8 100644
>> --- a/drivers/firmware/efi/unaccepted_memory.c
>> +++ b/drivers/firmware/efi/unaccepted_memory.c
>> @@ -36,6 +36,7 @@ void accept_memory(phys_addr_t start, unsigned long size)
>> unsigned long range_start, range_end;
>> struct accept_range range, *entry;
>> phys_addr_t end = start + size;
>> + phys_addr_t bitmap_end;
>> unsigned long flags;
>> u64 unit_size;
>>
>> @@ -44,6 +45,21 @@ void accept_memory(phys_addr_t start, unsigned long size)
>> return;
>>
>> unit_size = unaccepted->unit_size;
>> + bitmap_end = unaccepted->phys_base + unaccepted->size * unit_size * BITS_PER_BYTE;
>> +
>> + /* Memory completely beyond bitmap: hotplug memory, accept unconditionally */
>> + if (start >= bitmap_end) {
>> + arch_accept_memory(start, end);
>> + return;
>> + }
>> +
>> + /* Memory partially beyond bitmap */
>> + if (end > bitmap_end) {
>> + arch_accept_memory(bitmap_end, end);
>> + end = bitmap_end;
>> + }
>
> You are calling arch_accept_memory() on every memory allocation if the
> memory is not represented in the bitmap. Hard NAK.
In which scenarios would we not have memory represented in the bitmap?
Guests with <4 GiB? (how does kexec work?) Anything else?
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v4 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: Kiryl Shutsemau @ 2026-02-05 10:51 UTC (permalink / raw)
To: Pratik R. Sampat
Cc: David Hildenbrand (arm), linux-mm, linux-coco, x86, linux-kernel,
tglx, mingo, bp, dave.hansen, ardb, akpm, osalvador,
thomas.lendacky, michael.roth
In-Reply-To: <550c89ae-de6e-45f7-89a2-ccc815f8d5a2@amd.com>
On Wed, Feb 04, 2026 at 09:50:01PM -0600, Pratik R. Sampat wrote:
>
>
> On 2/4/26 1:59 PM, David Hildenbrand (arm) wrote:
> > On 2/4/26 12:22, Kiryl Shutsemau wrote:
> >> On Tue, Feb 03, 2026 at 11:49:45AM -0600, Pratik R. Sampat wrote:
> >>> Confidential computing guests require memory to be accepted before use.
> >>> The unaccepted memory bitmap maintained by firmware does not track
> >>> most hotplugged memory ranges apart from system memory annotated to be
> >>> cold plugged at boot.
> >>>
> >>> Explicitly validate and transition the newly added memory to a private
> >>> state, making it usable by the guest.
> >>>
> >>> Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
> >>> ---
> >>> drivers/firmware/efi/unaccepted_memory.c | 47 ++++++++++++++++++++++++
> >>> include/linux/mm.h | 5 +++
> >>> mm/memory_hotplug.c | 2 +
> >>> 3 files changed, 54 insertions(+)
> >>>
> >>> diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c
> >>> index c2c067eff634..359779133cb4 100644
> >>> --- a/drivers/firmware/efi/unaccepted_memory.c
> >>> +++ b/drivers/firmware/efi/unaccepted_memory.c
> >>> @@ -209,6 +209,53 @@ bool range_contains_unaccepted_memory(phys_addr_t start, unsigned long size)
> >>> return ret;
> >>> }
> >>> +/*
> >>> + * Unaccepted memory bitmap only covers initial boot memory and not the
> >>> + * hotpluggable range that is part of SRAT parsing. However, some initial memory
> >>> + * with the attribute EFI_MEMORY_HOT_PLUGGABLE can indicate boot time memory
> >>> + * that can be hot-removed. Hence post acceptance, only for that range update
> >>> + * the unaccepted bitmap to reflect this change.
> >>> + */
> >>> +void accept_hotplug_memory(phys_addr_t start, unsigned long size)
> >>> +{
> >>> + struct efi_unaccepted_memory *unaccepted;
> >>> + unsigned long range_start, range_len;
> >>> + phys_addr_t end = start + size;
> >>> + u64 phys_base, unit_size;
> >>> + unsigned long flags;
> >>> +
> >>> + unaccepted = efi_get_unaccepted_table();
> >>> + if (!unaccepted)
> >>> + return;
> >>
> >> This can be tricky.
> >>
> >> If we boot a VM with <4GiB of memory and all of it is pre-accepted by
> >> BIOS, the table will not be allocated.
> >>
> >> But it doesn't mean that hotplugged memory above should not be accepted.
> >>
> >> I don't think there is a way to detect such cases.
> >>
> >> Your check is probably the best we can do, but it means VMs are going to
> >> crash if memory accept is required by no table.
> >>
> >> This is ugly situation.
>
> Agreed. Breaking hotplug for VMs under 4G is absolutely not the way to go.
>
> Would it be worse if we call arch_accept_memory() if the table doesn't exist?
> The table is primarily to operate on the bitmap's entry. We could wrap these
> accept calls within an arch check for TDX and SNP guest if the unaccepted table
> is NULL. Or, less preferably convert the panic() of the existing
> arch_[accept/unaccept]_memory() to a WARN() instead.
I think you try to workaround a lack of proper design. I think the right
way would be to make unaccepted hotpluggable ranges declared upfront in
the EFI memory map, so kernel can allocate bitmap for all of it on boot
and not playing guessing game.
If it required EFI spec modification, let's do it.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v4 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: Kiryl Shutsemau @ 2026-02-05 10:48 UTC (permalink / raw)
To: Pratik R. Sampat
Cc: David Hildenbrand (arm), linux-mm, linux-coco, x86, linux-kernel,
tglx, mingo, bp, dave.hansen, ardb, akpm, osalvador,
thomas.lendacky, michael.roth
In-Reply-To: <70be936e-e49d-4485-8d1e-416fdf8f40a4@amd.com>
On Wed, Feb 04, 2026 at 09:50:09PM -0600, Pratik R. Sampat wrote:
>
>
> On 2/4/26 2:00 PM, David Hildenbrand (arm) wrote:
> >> #endif
> >> static inline bool pfn_is_unaccepted_memory(unsigned long pfn)
> >> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> >> index a63ec679d861..549ccfd190ee 100644
> >> --- a/mm/memory_hotplug.c
> >> +++ b/mm/memory_hotplug.c
> >> @@ -1567,6 +1567,8 @@ int add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)
> >> if (!strcmp(res->name, "System RAM"))
> >> firmware_map_add_hotplug(start, start + size, "System RAM");
> >> + accept_hotplug_memory(start, size);
> >> +
> >> /* device_online() will take the lock when calling online_pages() */
> >> mem_hotplug_done();
> >>
> >
> > I really hate that accepting (and un-accepting) hotplugged memory is different to accepting ordinary boot memory.
> >
> > Is there really no way we can get a reasonable implementation where we just call a generic accept_memory() and it will know what to do?
> >
>
> Sure, that shouldn't be impossible.
>
> The only reason I initially kept them separate is because we accept and update
> the bitmap unconditionally. This mainly applies to cold-plugged memory since
> their bitmap state after remove shouldn't matter. However, as we are now
> correctly setting the bits in the hot-remove path we should be fine accepting
> from the for_each_set_bitrange_from() logic within accept_memory(), I think.
>
> Something like so?
>
> diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c
> index d11e7836200a..e56adfd382f8 100644
> --- a/drivers/firmware/efi/unaccepted_memory.c
> +++ b/drivers/firmware/efi/unaccepted_memory.c
> @@ -36,6 +36,7 @@ void accept_memory(phys_addr_t start, unsigned long size)
> unsigned long range_start, range_end;
> struct accept_range range, *entry;
> phys_addr_t end = start + size;
> + phys_addr_t bitmap_end;
> unsigned long flags;
> u64 unit_size;
>
> @@ -44,6 +45,21 @@ void accept_memory(phys_addr_t start, unsigned long size)
> return;
>
> unit_size = unaccepted->unit_size;
> + bitmap_end = unaccepted->phys_base + unaccepted->size * unit_size * BITS_PER_BYTE;
> +
> + /* Memory completely beyond bitmap: hotplug memory, accept unconditionally */
> + if (start >= bitmap_end) {
> + arch_accept_memory(start, end);
> + return;
> + }
> +
> + /* Memory partially beyond bitmap */
> + if (end > bitmap_end) {
> + arch_accept_memory(bitmap_end, end);
> + end = bitmap_end;
> + }
You are calling arch_accept_memory() on every memory allocation if the
memory is not represented in the bitmap. Hard NAK.
>
> /*
> * Only care for the part of the range that is represented
>
> unaccept_hotplug_memory() truly doesn't do anything special for hotplug so I
> could just re-name it unaccept_memory().
>
> Thanks!
>
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [RFC PATCH v5 09/45] KVM: x86: Rework .free_external_spt() into .reclaim_external_sp()
From: Yan Zhao @ 2026-02-05 7:04 UTC (permalink / raw)
To: Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Kiryl Shutsemau, Paolo Bonzini,
linux-kernel, linux-coco, kvm, Kai Huang, Rick Edgecombe,
Vishal Annapurve, Ackerley Tng, Sagi Shahar, Binbin Wu,
Xiaoyao Li, Isaku Yamahata
In-Reply-To: <aYMVEX5OO22/Y72/@yzhao56-desk.sh.intel.com>
On Wed, Feb 04, 2026 at 05:45:39PM +0800, Yan Zhao wrote:
> On Wed, Jan 28, 2026 at 05:14:41PM -0800, Sean Christopherson wrote:
> > Massage .free_external_spt() into .reclaim_external_sp() to free up (pun
> > intended) "free" for actually freeing memory, and to allow TDX to do more
> > than just "free" the S-EPT entry. Specifically, nullify external_spt to
> > leak the S-EPT page if reclaiming the page fails, as that detail and
> > implementation choice has no business living in the TDP MMU.
> >
> > Use "sp" instead of "spt" even though "spt" is arguably more accurate, as
> > "spte" and "spt" are dangerously close in name, and because the key
> > parameter is a kvm_mmu_page, not a pointer to an S-EPT page table.
> >
> > Signed-off-by: Sean Christopherson <seanjc@google.com>
> > ---
> > arch/x86/include/asm/kvm-x86-ops.h | 2 +-
> > arch/x86/include/asm/kvm_host.h | 4 ++--
> > arch/x86/kvm/mmu/tdp_mmu.c | 13 ++-----------
> > arch/x86/kvm/vmx/tdx.c | 27 ++++++++++++---------------
> > 4 files changed, 17 insertions(+), 29 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/kvm-x86-ops.h b/arch/x86/include/asm/kvm-x86-ops.h
> > index 57eb1f4832ae..c17cedc485c9 100644
> > --- a/arch/x86/include/asm/kvm-x86-ops.h
> > +++ b/arch/x86/include/asm/kvm-x86-ops.h
> > @@ -95,8 +95,8 @@ KVM_X86_OP_OPTIONAL_RET0(set_identity_map_addr)
> > KVM_X86_OP_OPTIONAL_RET0(get_mt_mask)
> > KVM_X86_OP(load_mmu_pgd)
> > KVM_X86_OP_OPTIONAL_RET0(set_external_spte)
> > -KVM_X86_OP_OPTIONAL_RET0(free_external_spt)
> > KVM_X86_OP_OPTIONAL(remove_external_spte)
> > +KVM_X86_OP_OPTIONAL(reclaim_external_sp)
> > KVM_X86_OP(has_wbinvd_exit)
> > KVM_X86_OP(get_l2_tsc_offset)
> > KVM_X86_OP(get_l2_tsc_multiplier)
> > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> > index d12ca0f8a348..b35a07ed11fb 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -1858,8 +1858,8 @@ struct kvm_x86_ops {
> > u64 mirror_spte);
> >
> > /* Update external page tables for page table about to be freed. */
> > - int (*free_external_spt)(struct kvm *kvm, gfn_t gfn, enum pg_level level,
> > - void *external_spt);
> > + void (*reclaim_external_sp)(struct kvm *kvm, gfn_t gfn,
> > + struct kvm_mmu_page *sp);
> Do you think "free" is still better than "reclaim" though TDX actually
> invokes tdx_reclaim_page() to reclaim it on the TDX side?
>
> Naming it free_external_sp can be interpreted as freeing the sp->external_spt
> externally (vs freeing it in tdp_mmu_free_sp_rcu_callback(). This naming also
> allows for the future possibility of freeing sp->external_spt before the HKID is
> freed (though this is unlikely).
Oh. I found there's a free_external_sp() in patch 20.
So, maybe reclaim_external_sp() --> remove_external_spt() ?
Still think "sp" is not good :)
> > /* Update external page table from spte getting removed, and flush TLB. */
> > void (*remove_external_spte)(struct kvm *kvm, gfn_t gfn, enum pg_level level,
> > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> > index 27ac520f2a89..18764dbc97ea 100644
> > --- a/arch/x86/kvm/mmu/tdp_mmu.c
> > +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> > @@ -456,17 +456,8 @@ static void handle_removed_pt(struct kvm *kvm, tdp_ptep_t pt, bool shared)
> > old_spte, FROZEN_SPTE, level, shared);
> > }
> >
> > - if (is_mirror_sp(sp) &&
> > - WARN_ON(kvm_x86_call(free_external_spt)(kvm, base_gfn, sp->role.level,
> > - sp->external_spt))) {
> > - /*
> > - * Failed to free page table page in mirror page table and
> > - * there is nothing to do further.
> > - * Intentionally leak the page to prevent the kernel from
> > - * accessing the encrypted page.
> > - */
> > - sp->external_spt = NULL;
> > - }
> > + if (is_mirror_sp(sp))
> > + kvm_x86_call(reclaim_external_sp)(kvm, base_gfn, sp);
> >
> > call_rcu(&sp->rcu_head, tdp_mmu_free_sp_rcu_callback);
> > }
> > diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> > index 30494f9ceb31..66bc3ceb5e17 100644
> > --- a/arch/x86/kvm/vmx/tdx.c
> > +++ b/arch/x86/kvm/vmx/tdx.c
> > @@ -1783,27 +1783,24 @@ static void tdx_track(struct kvm *kvm)
> > kvm_make_all_cpus_request(kvm, KVM_REQ_OUTSIDE_GUEST_MODE);
> > }
> >
> > -static int tdx_sept_free_private_spt(struct kvm *kvm, gfn_t gfn,
> > - enum pg_level level, void *private_spt)
> > +static void tdx_sept_reclaim_private_sp(struct kvm *kvm, gfn_t gfn,
> > + struct kvm_mmu_page *sp)
> Passing in "sp" and having "reclaim_private_sp" in the function name is bit
> confusing.
> Strictly speaking, only sp->external_spt is private, while the sp and sp->spt
> are just mirroring the external spt.
>
> But I understand it's for setting sp->external_spt to NULL on error.
>
> > {
> > - struct kvm_tdx *kvm_tdx = to_kvm_tdx(kvm);
> > -
> > /*
> > - * free_external_spt() is only called after hkid is freed when TD is
> > - * tearing down.
> > * KVM doesn't (yet) zap page table pages in mirror page table while
> > * TD is active, though guest pages mapped in mirror page table could be
> > * zapped during TD is active, e.g. for shared <-> private conversion
> > * and slot move/deletion.
> > + *
> > + * In other words, KVM should only free mirror page tables after the
> > + * TD's hkid is freed, when the TD is being torn down.
> > + *
> > + * If the S-EPT PTE can't be removed for any reason, intentionally leak
> > + * the page to prevent the kernel from accessing the encrypted page.
> > */
> > - if (KVM_BUG_ON(is_hkid_assigned(kvm_tdx), kvm))
> > - return -EIO;
> > -
> > - /*
> > - * The HKID assigned to this TD was already freed and cache was
> > - * already flushed. We don't have to flush again.
> > - */
> > - return tdx_reclaim_page(virt_to_page(private_spt));
> > + if (KVM_BUG_ON(is_hkid_assigned(to_kvm_tdx(kvm)), kvm) ||
> > + tdx_reclaim_page(virt_to_page(sp->external_spt)))
> > + sp->external_spt = NULL;
> > }
> >
> > static void tdx_sept_remove_private_spte(struct kvm *kvm, gfn_t gfn,
> > @@ -3617,7 +3614,7 @@ void __init tdx_hardware_setup(void)
> > vt_x86_ops.vm_size = max_t(unsigned int, vt_x86_ops.vm_size, sizeof(struct kvm_tdx));
> >
> > vt_x86_ops.set_external_spte = tdx_sept_set_private_spte;
> > - vt_x86_ops.free_external_spt = tdx_sept_free_private_spt;
> > + vt_x86_ops.reclaim_external_sp = tdx_sept_reclaim_private_sp;
> > vt_x86_ops.remove_external_spte = tdx_sept_remove_private_spte;
> > vt_x86_ops.protected_apic_has_interrupt = tdx_protected_apic_has_interrupt;
> > }
> > --
> > 2.53.0.rc1.217.geba53bf80e-goog
> >
^ permalink raw reply
* Re: [RFC PATCH v5 16/45] x86/virt/tdx: Add tdx_alloc/free_control_page() helpers
From: Yan Zhao @ 2026-02-05 6:11 UTC (permalink / raw)
To: Sean Christopherson
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Paolo Bonzini, linux-kernel, linux-coco, kvm,
Kai Huang, Rick Edgecombe, Vishal Annapurve, Ackerley Tng,
Sagi Shahar, Binbin Wu, Xiaoyao Li, Isaku Yamahata
In-Reply-To: <20260129011517.3545883-17-seanjc@google.com>
> +void tdx_quirk_reset_page(struct page *page);
Looks this change is unnecessary.
> int tdx_guest_keyid_alloc(void);
> u32 tdx_get_nr_guest_keyids(void);
> void tdx_guest_keyid_free(unsigned int keyid);
>
> -void tdx_quirk_reset_page(struct page *page);
> +struct page *__tdx_alloc_control_page(gfp_t gfp);
> +void __tdx_free_control_page(struct page *page);
> +
> +static inline unsigned long tdx_alloc_control_page(gfp_t gfp)
> +{
> + struct page *page = __tdx_alloc_control_page(gfp);
> +
> + if (!page)
> + return 0;
> +
> + return (unsigned long)page_address(page);
> +}
> +
> +static inline void tdx_free_control_page(unsigned long addr)
> +{
> + if (!addr)
> + return;
> +
> + __tdx_free_control_page(virt_to_page(addr));
> +}
>
> struct tdx_td {
> /* TD root structure: */
> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index f6e80aba5895..682c8a228b53 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c
> @@ -1824,6 +1824,50 @@ u64 tdh_mng_rd(struct tdx_td *td, u64 field, u64 *data)
> }
> EXPORT_SYMBOL_FOR_KVM(tdh_mng_rd);
>
> +/* Number PAMT pages to be provided to TDX module per 2M region of PA */
> +static int tdx_dpamt_entry_pages(void)
> +{
> + if (!tdx_supports_dynamic_pamt(&tdx_sysinfo))
> + return 0;
> +
This function is not invoked when !tdx_supports_dynamic_pamt().
So, probably we can just return the count below?
> + return tdx_sysinfo.tdmr.pamt_4k_entry_size * PTRS_PER_PTE / PAGE_SIZE;
> +}
> +
^ permalink raw reply
* Re: [RFC PATCH v5 08/45] KVM: x86/mmu: Propagate mirror SPTE removal to S-EPT in handle_changed_spte()
From: Yan Zhao @ 2026-02-05 5:39 UTC (permalink / raw)
To: Sean Christopherson
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Paolo Bonzini, linux-kernel, linux-coco, kvm,
Kai Huang, Rick Edgecombe, Vishal Annapurve, Ackerley Tng,
Sagi Shahar, Binbin Wu, Xiaoyao Li, Isaku Yamahata
In-Reply-To: <aYP_Ko3FGRriGXWR@google.com>
On Wed, Feb 04, 2026 at 06:23:38PM -0800, Sean Christopherson wrote:
> On Wed, Feb 04, 2026, Yan Zhao wrote:
> > On Wed, Jan 28, 2026 at 05:14:40PM -0800, Sean Christopherson wrote:
> > > @@ -590,10 +566,21 @@ static void handle_changed_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
> > > * the paging structure. Note the WARN on the PFN changing without the
> > > * SPTE being converted to a hugepage (leaf) or being zapped. Shadow
> > > * pages are kernel allocations and should never be migrated.
> > > + *
> > > + * When removing leaf entries from a mirror, immediately propagate the
> > > + * changes to the external page tables. Note, non-leaf mirror entries
> > > + * are handled by handle_removed_pt(), as TDX requires that all leaf
> > > + * entries are removed before the owning page table. Note #2, writes
> > > + * to make mirror PTEs shadow-present are propagated to external page
> > > + * tables by __tdp_mmu_set_spte_atomic(), as KVM needs to ensure the
> > > + * external page table was successfully updated before marking the
> > > + * mirror SPTE present.
> > > */
> > > if (was_present && !was_leaf &&
> > > (is_leaf || !is_present || WARN_ON_ONCE(pfn_changed)))
> > > handle_removed_pt(kvm, spte_to_child_pt(old_spte, level), shared);
> > > + else if (was_leaf && is_mirror_sptep(sptep) && !is_leaf)
> > Should we check !is_present instead of !is_leaf?
> > e.g. a transition from a present leaf entry to a present non-leaf entry could
> > also trigger this if case.
>
> No, the !is_leaf check is very intentional. At this point in the series, S-EPT
> doesn't support hugepages. If KVM manages to install a leaf SPTE and replaces
> that SPTE with a non-leaf SPTE, then we absolutely want the KVM_BUG_ON() in
> tdx_sept_remove_private_spte() to fire:
>
> /* TODO: handle large pages. */
> if (KVM_BUG_ON(level != PG_LEVEL_4K, kvm))
> return -EIO;
But the op is named remove_external_spte().
And the check of "level != PG_LEVEL_4K" is for removing large leaf entries.
Relying on this check is tricky and confusing.
> And then later on, when S-EPT gains support for hugepages, "KVM: TDX: Add core
> support for splitting/demoting 2MiB S-EPT to 4KiB" doesn't need to touch code
> outside of arch/x86/kvm/vmx/tdx.c, because everything has already been plumbed
> in.
I haven't looked at the later patches for huge pages, but plumbing here directly
for splitting does not look right when it's invoked under shared mmu_lock.
See the comment below.
> > Besides, need "KVM_BUG_ON(shared, kvm)" in this case.
>
> Eh, we have lockdep_assert_held_write() in the S-EPT paths that require mmu_lock
> to be held for write. I don't think a KVM_BUG_ON() here would add meaningful
> value.
Hmm, I think KVM_BUG_ON(shared, kvm) is still useful.
If KVM invokes remove_external_spte() under shared mmu_lock, it needs to freeze
the entry first, similar to the sequence in __tdp_mmu_set_spte_atomic().
i.e., invoking external x86 ops in handle_changed_spte() for mirror roots should
be !shared only.
Relying on the TDX code's lockdep_assert_held_write() for warning seems less
clear than having an explicit check here.
^ permalink raw reply
* Re: [PATCH v4 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: Pratik R. Sampat @ 2026-02-05 3:50 UTC (permalink / raw)
To: David Hildenbrand (arm), linux-mm, linux-coco, x86, linux-kernel
Cc: tglx, mingo, bp, dave.hansen, kas, ardb, akpm, osalvador,
thomas.lendacky, michael.roth
In-Reply-To: <d07cbb96-ba30-4dcf-ad14-0479d6a989f2@kernel.org>
On 2/4/26 2:00 PM, David Hildenbrand (arm) wrote:
>> #endif
>> static inline bool pfn_is_unaccepted_memory(unsigned long pfn)
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index a63ec679d861..549ccfd190ee 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -1567,6 +1567,8 @@ int add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)
>> if (!strcmp(res->name, "System RAM"))
>> firmware_map_add_hotplug(start, start + size, "System RAM");
>> + accept_hotplug_memory(start, size);
>> +
>> /* device_online() will take the lock when calling online_pages() */
>> mem_hotplug_done();
>>
>
> I really hate that accepting (and un-accepting) hotplugged memory is different to accepting ordinary boot memory.
>
> Is there really no way we can get a reasonable implementation where we just call a generic accept_memory() and it will know what to do?
>
Sure, that shouldn't be impossible.
The only reason I initially kept them separate is because we accept and update
the bitmap unconditionally. This mainly applies to cold-plugged memory since
their bitmap state after remove shouldn't matter. However, as we are now
correctly setting the bits in the hot-remove path we should be fine accepting
from the for_each_set_bitrange_from() logic within accept_memory(), I think.
Something like so?
diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c
index d11e7836200a..e56adfd382f8 100644
--- a/drivers/firmware/efi/unaccepted_memory.c
+++ b/drivers/firmware/efi/unaccepted_memory.c
@@ -36,6 +36,7 @@ void accept_memory(phys_addr_t start, unsigned long size)
unsigned long range_start, range_end;
struct accept_range range, *entry;
phys_addr_t end = start + size;
+ phys_addr_t bitmap_end;
unsigned long flags;
u64 unit_size;
@@ -44,6 +45,21 @@ void accept_memory(phys_addr_t start, unsigned long size)
return;
unit_size = unaccepted->unit_size;
+ bitmap_end = unaccepted->phys_base + unaccepted->size * unit_size * BITS_PER_BYTE;
+
+ /* Memory completely beyond bitmap: hotplug memory, accept unconditionally */
+ if (start >= bitmap_end) {
+ arch_accept_memory(start, end);
+ return;
+ }
+
+ /* Memory partially beyond bitmap */
+ if (end > bitmap_end) {
+ arch_accept_memory(bitmap_end, end);
+ end = bitmap_end;
+ }
/*
* Only care for the part of the range that is represented
unaccept_hotplug_memory() truly doesn't do anything special for hotplug so I
could just re-name it unaccept_memory().
Thanks!
^ permalink raw reply related
* Re: [PATCH v4 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: Pratik R. Sampat @ 2026-02-05 3:50 UTC (permalink / raw)
To: David Hildenbrand (arm), Kiryl Shutsemau
Cc: linux-mm, linux-coco, x86, linux-kernel, tglx, mingo, bp,
dave.hansen, ardb, akpm, osalvador, thomas.lendacky, michael.roth
In-Reply-To: <29b4dc97-bb01-42fd-8ccd-f4cb2886ccd3@kernel.org>
On 2/4/26 1:59 PM, David Hildenbrand (arm) wrote:
> On 2/4/26 12:22, Kiryl Shutsemau wrote:
>> On Tue, Feb 03, 2026 at 11:49:45AM -0600, Pratik R. Sampat wrote:
>>> Confidential computing guests require memory to be accepted before use.
>>> The unaccepted memory bitmap maintained by firmware does not track
>>> most hotplugged memory ranges apart from system memory annotated to be
>>> cold plugged at boot.
>>>
>>> Explicitly validate and transition the newly added memory to a private
>>> state, making it usable by the guest.
>>>
>>> Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
>>> ---
>>> drivers/firmware/efi/unaccepted_memory.c | 47 ++++++++++++++++++++++++
>>> include/linux/mm.h | 5 +++
>>> mm/memory_hotplug.c | 2 +
>>> 3 files changed, 54 insertions(+)
>>>
>>> diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c
>>> index c2c067eff634..359779133cb4 100644
>>> --- a/drivers/firmware/efi/unaccepted_memory.c
>>> +++ b/drivers/firmware/efi/unaccepted_memory.c
>>> @@ -209,6 +209,53 @@ bool range_contains_unaccepted_memory(phys_addr_t start, unsigned long size)
>>> return ret;
>>> }
>>> +/*
>>> + * Unaccepted memory bitmap only covers initial boot memory and not the
>>> + * hotpluggable range that is part of SRAT parsing. However, some initial memory
>>> + * with the attribute EFI_MEMORY_HOT_PLUGGABLE can indicate boot time memory
>>> + * that can be hot-removed. Hence post acceptance, only for that range update
>>> + * the unaccepted bitmap to reflect this change.
>>> + */
>>> +void accept_hotplug_memory(phys_addr_t start, unsigned long size)
>>> +{
>>> + struct efi_unaccepted_memory *unaccepted;
>>> + unsigned long range_start, range_len;
>>> + phys_addr_t end = start + size;
>>> + u64 phys_base, unit_size;
>>> + unsigned long flags;
>>> +
>>> + unaccepted = efi_get_unaccepted_table();
>>> + if (!unaccepted)
>>> + return;
>>
>> This can be tricky.
>>
>> If we boot a VM with <4GiB of memory and all of it is pre-accepted by
>> BIOS, the table will not be allocated.
>>
>> But it doesn't mean that hotplugged memory above should not be accepted.
>>
>> I don't think there is a way to detect such cases.
>>
>> Your check is probably the best we can do, but it means VMs are going to
>> crash if memory accept is required by no table.
>>
>> This is ugly situation.
Agreed. Breaking hotplug for VMs under 4G is absolutely not the way to go.
Would it be worse if we call arch_accept_memory() if the table doesn't exist?
The table is primarily to operate on the bitmap's entry. We could wrap these
accept calls within an arch check for TDX and SNP guest if the unaccepted table
is NULL. Or, less preferably convert the panic() of the existing
arch_[accept/unaccept]_memory() to a WARN() instead.
>
> It's all starting to feel .... very hacky, sorry to say.
>
> This should all be easier. If we expect memory hotplug (SRAT), why can't we just allocate the bitmap properly?
>
The unaccepted bitmap allocation happens a lot earlier than SRAT parsing. So to
get the right range, either we have to duplicate some of that parsing logic
earlier, or, replace the memblock allocated bitmap later. The first one is a
bit more hacky, but the second one would require us to the change the original
unaccepted struct from a flexible array to a pointer which might break kexec.
Neither of the approaches seem less intrusive than the other unfortunately.
--Pratik
^ permalink raw reply
* Re: [RFC PATCH v5 08/45] KVM: x86/mmu: Propagate mirror SPTE removal to S-EPT in handle_changed_spte()
From: Sean Christopherson @ 2026-02-05 2:23 UTC (permalink / raw)
To: Yan Zhao
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Paolo Bonzini, linux-kernel, linux-coco, kvm,
Kai Huang, Rick Edgecombe, Vishal Annapurve, Ackerley Tng,
Sagi Shahar, Binbin Wu, Xiaoyao Li, Isaku Yamahata
In-Reply-To: <aYMMHVvwDjZ7Lz9l@yzhao56-desk.sh.intel.com>
On Wed, Feb 04, 2026, Yan Zhao wrote:
> On Wed, Jan 28, 2026 at 05:14:40PM -0800, Sean Christopherson wrote:
> > @@ -590,10 +566,21 @@ static void handle_changed_spte(struct kvm *kvm, int as_id, tdp_ptep_t sptep,
> > * the paging structure. Note the WARN on the PFN changing without the
> > * SPTE being converted to a hugepage (leaf) or being zapped. Shadow
> > * pages are kernel allocations and should never be migrated.
> > + *
> > + * When removing leaf entries from a mirror, immediately propagate the
> > + * changes to the external page tables. Note, non-leaf mirror entries
> > + * are handled by handle_removed_pt(), as TDX requires that all leaf
> > + * entries are removed before the owning page table. Note #2, writes
> > + * to make mirror PTEs shadow-present are propagated to external page
> > + * tables by __tdp_mmu_set_spte_atomic(), as KVM needs to ensure the
> > + * external page table was successfully updated before marking the
> > + * mirror SPTE present.
> > */
> > if (was_present && !was_leaf &&
> > (is_leaf || !is_present || WARN_ON_ONCE(pfn_changed)))
> > handle_removed_pt(kvm, spte_to_child_pt(old_spte, level), shared);
> > + else if (was_leaf && is_mirror_sptep(sptep) && !is_leaf)
> Should we check !is_present instead of !is_leaf?
> e.g. a transition from a present leaf entry to a present non-leaf entry could
> also trigger this if case.
No, the !is_leaf check is very intentional. At this point in the series, S-EPT
doesn't support hugepages. If KVM manages to install a leaf SPTE and replaces
that SPTE with a non-leaf SPTE, then we absolutely want the KVM_BUG_ON() in
tdx_sept_remove_private_spte() to fire:
/* TODO: handle large pages. */
if (KVM_BUG_ON(level != PG_LEVEL_4K, kvm))
return -EIO;
And then later on, when S-EPT gains support for hugepages, "KVM: TDX: Add core
support for splitting/demoting 2MiB S-EPT to 4KiB" doesn't need to touch code
outside of arch/x86/kvm/vmx/tdx.c, because everything has already been plumbed
in.
> Besides, need "KVM_BUG_ON(shared, kvm)" in this case.
Eh, we have lockdep_assert_held_write() in the S-EPT paths that require mmu_lock
to be held for write. I don't think a KVM_BUG_ON() here would add meaningful
value.
^ permalink raw reply
* Re: [GIT PULL] PCIe Link Encryption fixes for 6.19
From: pr-tracker-bot @ 2026-02-04 23:25 UTC (permalink / raw)
To: dan.j.williams
Cc: Linus Torvalds, linux-coco, linux-pci, linux-kernel,
Alexey Kardashevskiy, Xu Yilun, Aneesh Kumar K.V (Arm)
In-Reply-To: <6983bd3a3a3ae_68d310016@dwillia2-mobl4.notmuch>
The pull request you sent on Wed, 4 Feb 2026 13:42:18 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm tags/tsm-fixes-for-6.19
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f14faaf3a1fb3b9e4cf2e56269711fb85fba9458
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: SVSM Development Call February 4, 2026
From: Jörg Rödel @ 2026-02-04 21:50 UTC (permalink / raw)
To: coconut-svsm, linux-coco
In-Reply-To: <lcirfa4dfkyv2522vuwr4dth2lbzi2sunhcubojuarg6v2myfx@bf33fftemnmj>
Meeting minutes are ready:
https://github.com/coconut-svsm/governance/pull/95
-Jörg
^ permalink raw reply
* [GIT PULL] PCIe Link Encryption fixes for 6.19
From: dan.j.williams @ 2026-02-04 21:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-coco, linux-pci, linux-kernel, Alexey Kardashevskiy,
Xu Yilun, Aneesh Kumar K.V (Arm)
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm tags/tsm-fixes-for-6.19
...to receive a small collection of fixes for 6.19. The largest change
is reverting part of an ABI that never shipped in a released kernel
(Documentation/ABI/testing/sysfs-class-tsm). The fix / replacement for
that is too large to squeeze in at this late date. The rest is a
collection of small fixups summarized in the tag message.
It has appeared in linux-next with no reports at last check.
Given the tsm.git tree merged the PCIe Link Encryption support for the
AMD "ccp" driver, Alexey asked that the fixes also go through the
tsm.git with an ack from Tom. Bjorn acked taking ide.c fixes through
tsm.git as well.
---
The following changes since commit 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7:
Linux 6.19-rc6 (2026-01-18 15:42:45 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm tags/tsm-fixes-for-6.19
for you to fetch changes up to c2012263047689e495e81c96d7d5b0586299578d:
crypto/ccp: Allow multiple streams on the same root bridge (2026-01-30 14:27:53 -0800)
----------------------------------------------------------------
tsm fixes for 6.19
- Fix multiple streams per host bridge for SEV-TIO
- Drop the TSM ABI for reporting IDE streams (to be replaced)
- Fix virtual function enumeration
- Fix reserved stream ID initialization
- Fix unused variable compiler warning
----------------------------------------------------------------
Alexey Kardashevskiy (2):
crypto/ccp: Use PCI bridge defaults for IDE
crypto/ccp: Allow multiple streams on the same root bridge
Dan Williams (1):
Revert "PCI/TSM: Report active IDE streams"
Li Ming (2):
PCI/IDE: Fix off by one error calculating VF RID range
PCI/IDE: Fix reading a wrong reg for unused sel stream initialization
Thomas Weißschuh (1):
coco/tsm: Remove unused variable tsm_rwsem
Documentation/ABI/testing/sysfs-class-tsm | 10 ----------
drivers/crypto/ccp/sev-dev-tsm.c | 15 +--------------
drivers/pci/ide.c | 10 +++-------
drivers/virt/coco/tsm-core.c | 30 ------------------------------
include/linux/pci-ide.h | 4 +---
include/linux/tsm.h | 3 ---
6 files changed, 5 insertions(+), 67 deletions(-)
^ permalink raw reply
* Re: [PATCH v4 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: David Hildenbrand (arm) @ 2026-02-04 20:00 UTC (permalink / raw)
To: Pratik R. Sampat, linux-mm, linux-coco, x86, linux-kernel
Cc: tglx, mingo, bp, dave.hansen, kas, ardb, akpm, osalvador,
thomas.lendacky, michael.roth
In-Reply-To: <20260203174946.1198053-2-prsampat@amd.com>
> #endif
>
> static inline bool pfn_is_unaccepted_memory(unsigned long pfn)
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index a63ec679d861..549ccfd190ee 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1567,6 +1567,8 @@ int add_memory_resource(int nid, struct resource *res, mhp_t mhp_flags)
> if (!strcmp(res->name, "System RAM"))
> firmware_map_add_hotplug(start, start + size, "System RAM");
>
> + accept_hotplug_memory(start, size);
> +
> /* device_online() will take the lock when calling online_pages() */
> mem_hotplug_done();
>
I really hate that accepting (and un-accepting) hotplugged memory is
different to accepting ordinary boot memory.
Is there really no way we can get a reasonable implementation where we
just call a generic accept_memory() and it will know what to do?
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v4 1/2] mm/memory_hotplug: Add support to accept memory during hot-add
From: David Hildenbrand (arm) @ 2026-02-04 19:59 UTC (permalink / raw)
To: Kiryl Shutsemau, Pratik R. Sampat
Cc: linux-mm, linux-coco, x86, linux-kernel, tglx, mingo, bp,
dave.hansen, ardb, akpm, osalvador, thomas.lendacky, michael.roth
In-Reply-To: <aYMjjyVVax5cml9B@thinkstation>
On 2/4/26 12:22, Kiryl Shutsemau wrote:
> On Tue, Feb 03, 2026 at 11:49:45AM -0600, Pratik R. Sampat wrote:
>> Confidential computing guests require memory to be accepted before use.
>> The unaccepted memory bitmap maintained by firmware does not track
>> most hotplugged memory ranges apart from system memory annotated to be
>> cold plugged at boot.
>>
>> Explicitly validate and transition the newly added memory to a private
>> state, making it usable by the guest.
>>
>> Signed-off-by: Pratik R. Sampat <prsampat@amd.com>
>> ---
>> drivers/firmware/efi/unaccepted_memory.c | 47 ++++++++++++++++++++++++
>> include/linux/mm.h | 5 +++
>> mm/memory_hotplug.c | 2 +
>> 3 files changed, 54 insertions(+)
>>
>> diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c
>> index c2c067eff634..359779133cb4 100644
>> --- a/drivers/firmware/efi/unaccepted_memory.c
>> +++ b/drivers/firmware/efi/unaccepted_memory.c
>> @@ -209,6 +209,53 @@ bool range_contains_unaccepted_memory(phys_addr_t start, unsigned long size)
>> return ret;
>> }
>>
>> +/*
>> + * Unaccepted memory bitmap only covers initial boot memory and not the
>> + * hotpluggable range that is part of SRAT parsing. However, some initial memory
>> + * with the attribute EFI_MEMORY_HOT_PLUGGABLE can indicate boot time memory
>> + * that can be hot-removed. Hence post acceptance, only for that range update
>> + * the unaccepted bitmap to reflect this change.
>> + */
>> +void accept_hotplug_memory(phys_addr_t start, unsigned long size)
>> +{
>> + struct efi_unaccepted_memory *unaccepted;
>> + unsigned long range_start, range_len;
>> + phys_addr_t end = start + size;
>> + u64 phys_base, unit_size;
>> + unsigned long flags;
>> +
>> + unaccepted = efi_get_unaccepted_table();
>> + if (!unaccepted)
>> + return;
>
> This can be tricky.
>
> If we boot a VM with <4GiB of memory and all of it is pre-accepted by
> BIOS, the table will not be allocated.
>
> But it doesn't mean that hotplugged memory above should not be accepted.
>
> I don't think there is a way to detect such cases.
>
> Your check is probably the best we can do, but it means VMs are going to
> crash if memory accept is required by no table.
>
> This is ugly situation.
It's all starting to feel .... very hacky, sorry to say.
This should all be easier. If we expect memory hotplug (SRAT), why can't
we just allocate the bitmap properly?
--
Cheers,
David
^ permalink raw reply
* Re: [RFC PATCH v5 00/45] TDX: Dynamic PAMT + S-EPT Hugepage
From: Dave Hansen @ 2026-02-04 15:09 UTC (permalink / raw)
To: Sean Christopherson, Konrad Rzeszutek Wilk
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Paolo Bonzini, linux-kernel, linux-coco, kvm,
Kai Huang, Rick Edgecombe, Yan Zhao, Vishal Annapurve,
Ackerley Tng, Sagi Shahar, Binbin Wu, Xiaoyao Li, Isaku Yamahata
In-Reply-To: <aYNaA7Td23xKHoHK@google.com>
On 2/4/26 06:38, Sean Christopherson wrote:
...
> We can and do have tests and VMM support, but it's all out-of-tree (for now).
> All I'm saying here is that I'm ok landing the S-EPT hugepage code in advance of
> guest_memfd hugepage support, e.g. so that we don't end up in a stalemate due to
> cyclical dependecies, or one big megaseries.
Does "landing" mean having it sit in some topic branch, or pushing to Linus?
I'm all for getting these hellish dependency chains out of the way, but
we usually try pretty hard to avoid having dead/unreachable code in
mainline.
If it is something you want to do in mainline, we should probably do a
bit of cross-x86/kvm brainstorming to make sure there's no other option.
^ permalink raw reply
* Re: [RFC PATCH v5 00/45] TDX: Dynamic PAMT + S-EPT Hugepage
From: Sean Christopherson @ 2026-02-04 14:38 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
Kiryl Shutsemau, Paolo Bonzini, linux-kernel, linux-coco, kvm,
Kai Huang, Rick Edgecombe, Yan Zhao, Vishal Annapurve,
Ackerley Tng, Sagi Shahar, Binbin Wu, Xiaoyao Li, Isaku Yamahata
In-Reply-To: <aXuVR0kq_K1TYwlR@char.us.oracle.com>
On Thu, Jan 29, 2026, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 28, 2026 at 05:14:32PM -0800, Sean Christopherson wrote:
> > This is a combined series of Dynamic PAMT (from Rick), and S-EPT hugepage
> > support (from Yan). Except for some last minute tweaks to the DPAMT array
> > args stuff, a version of this based on a Google-internal kernel has been
> > moderately well tested (thanks Vishal!). But overall it's still firmly RFC
> > as I have deliberately NOT addressed others feedback from v4 of DPAMT and v3
>
> What does PAMT stand for? Is there a design document somewhere?
>
> > of S-EPT hugepage (mostly lack of cycles), and there's at least one patch in
> > here that shouldn't be merged as-is (the quick-and-dirty switch from struct
> > page to raw pfns).
> >
> > My immediate goal is to solidify the designs for DPAMT and S-EPT hugepage.
> > Given the substantial design changes I am proposing, posting an end-to-end
> > RFC seemed like a much better method than trying to communicate my thoughts
> > piecemeal.
> >
> > As for landing these series, I think the fastest overall approach would be
> > to land patches 1-4 asap (tangentially related cleanups and fixes), agree
>
> Should they be split out as non-RFC then?
Yeah, I'll do that soonish. I posted the kitchen sink so that people could
review the entire thing without having to chase down 4+ series/patches.
> > on a design (hopefully), and then hand control back to Rick and Yan to polish
> > their respective series for merge.
> >
> > I also want to land the VMXON series[*] before DPAMT, because there's a nasty
> > wart where KVM wires up a DPAMT-specific hook even if DPAMT is disabled,
> > because KVM's ordering needs to set the vendor hooks before tdx_sysinfo is
> > ready. Decoupling VMXON from KVM solves that problem, because it lets the
> > TDX subsystem parse sysinfo before TDX is loaded.
> >
> > Beyond that dependency, I am comfortable landing both DPAMT and S-EPT hugepage
> > support without any other prereqs, i.e. without an in-tree way to light up
> > the S-EPT hugepage code due to lack of hugepage support in guest_memfd.
>
> Can there be test-cases? Or simple code posted for QEMU which is the
> tool that 99% of kernel engineers use?
No? The core limitation is that KVM doesn't yet support hugepages for private
memory. No amount userspace code can overcome that limitation.
We can and do have tests and VMM support, but it's all out-of-tree (for now).
All I'm saying here is that I'm ok landing the S-EPT hugepage code in advance of
guest_memfd hugepage support, e.g. so that we don't end up in a stalemate due to
cyclical dependecies, or one big megaseries.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox