Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Sagi Shahar <sagis@google.com>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
	Alexander Graf <graf@amazon.com>,
	"Andersen, Tycho" <Tycho.Andersen@amd.com>,
	Anthony Yznaga <anthony.yznaga@oracle.com>,
	Baolu Lu <baolu.lu@linux.intel.com>,
	David Hildenbrand <david@kernel.org>,
	David Matlack <dmatlack@google.com>,
	"Heyne, Maximillian" <mheyne@amazon.de>,
	James Gowans <jgowans@amazon.com>,
	Jason Gunthorpe <jgg@nvidia.com>, Mike Rapoport <rppt@kernel.org>,
	Pankaj Gupta <pankaj.gupta.linux@gmail.com>,
	Pratyush Yadav <pratyush@kernel.org>,
	Praveen Kumar <kpraveen.lkml@gmail.com>,
	Vipin Sharma <vipinsh@google.com>,
	Vishal Annapurve <vannapurve@google.com>,
	"Woodhouse, David" <dwmw@amazon.co.uk>,
	Luca Boccassi <luca.boccassi@gmail.com>,
	Samiullah Khawaja <skhawaja@google.com>,
	Jork Loeser <jloeser@linux.microsoft.com>,
	Chenghao Duan <duanchenghao@kylinos.cn>,
	Zhu Yanjun <yanjun.zhu@linux.dev>,
	Sean Christopherson <seanjc@google.com>,
	"Verma, Vishal L" <vishal.l.verma@intel.com>,
	linux-mm@kvack.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: Preserving TDX module during kexec with live update
Date: Thu, 16 Jul 2026 10:55:38 -0400	[thread overview]
Message-ID: <aljw6vDaeEdhzZdy@google.com> (raw)
In-Reply-To: <CAAhR5DGpL6_ViMwQ0nKzTgOoziE_oq8JofpO-VtHBXK37uO-FA@mail.gmail.com>

On 07-15 18:28, Sagi Shahar wrote:
> Hi,
> 
> I started looking into preserving the TDX module across live updates
> and I'm not sure what the best approach is. I tried looking into using
> flb as David M suggested but I don't think this approach works for the
> TDX module.
> 
> Right now the way that TDX supports kexec is by disabling the TDX
> module on kexec and then reinitilizing it on the next boot [1]. This
> approach clears the TDX module state so any TDX VM from the source
> kernel won't be able to resume running on the destination kernel.
> 
> In order to support live update while keeping the VMs alive we need to
> skip the TDH_SYS_DISABLE call and instead preserve pages used by the
> TDX module such as the TDMR pages from the source kernel.

Agreed.

> 
> From what I understand, using flb will tie the TDX module save/restore
> to the lifecycle of the VMs depending on it. This means the module
> will be restored too late during kernel boot, after the VMs are
> restored using the live update IOCTLs.

That is not correct. FLBs specifically can be restored very early in 
boot. We do that for HugeTLB preservation, for example.

liveupdate_flb_get_incoming() does not require userspace to resume or 
restore VMs. You can call it super early in boot to see if there is FLB 
data present and, if so, change the way the module is initialized during 
boot.

> 
> I'm thinking we should preserve the TDX module during the shutdown
> stage of the source kernel. Perhaps we can preserve the pages used by
> the TDX module as we allocate them on the source kernel and pass
> pointers and additional metadata during KHO. Then on the destination
> we need to pipe this information to where the TDX module gets
> initialized during the KVM module initialization.

Please don't invent another state machine; instead, use the existing 
one.

Pasha

> 
> I haven't found a device that acts in a similar way so I'm not sure
> how complicated this will be or if there's a better approach.
> 
> I would love to hear your thoughts and if you have any pointers on
> where this code can be implemented.
> 
> Thanks,
> Sagi
> 
> [1] https://lore.kernel.org/all/20260323-fuller_tdx_kexec_support-v2-0-87a36409e051@intel.com/


      reply	other threads:[~2026-07-16 14:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 23:28 Preserving TDX module during kexec with live update Sagi Shahar
2026-07-16 14:55 ` Pasha Tatashin [this message]

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=aljw6vDaeEdhzZdy@google.com \
    --to=pasha.tatashin@soleen.com \
    --cc=Tycho.Andersen@amd.com \
    --cc=anthony.yznaga@oracle.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=david@kernel.org \
    --cc=dmatlack@google.com \
    --cc=duanchenghao@kylinos.cn \
    --cc=dwmw@amazon.co.uk \
    --cc=graf@amazon.com \
    --cc=jgg@nvidia.com \
    --cc=jgowans@amazon.com \
    --cc=jloeser@linux.microsoft.com \
    --cc=kexec@lists.infradead.org \
    --cc=kpraveen.lkml@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luca.boccassi@gmail.com \
    --cc=mheyne@amazon.de \
    --cc=pankaj.gupta.linux@gmail.com \
    --cc=pratyush@kernel.org \
    --cc=rppt@kernel.org \
    --cc=sagis@google.com \
    --cc=seanjc@google.com \
    --cc=skhawaja@google.com \
    --cc=vannapurve@google.com \
    --cc=vipinsh@google.com \
    --cc=vishal.l.verma@intel.com \
    --cc=yanjun.zhu@linux.dev \
    /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