public inbox for linux-coco@lists.linux.dev
 help / color / mirror / Atom feed
From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "Reshetova, Elena" <elena.reshetova@intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"prsampat@amd.com" <prsampat@amd.com>,
	"Duan, Zhenzhong" <zhenzhong.duan@intel.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"marcandre.lureau@redhat.com" <marcandre.lureau@redhat.com>,
	"kas@kernel.org" <kas@kernel.org>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"Qiang, Chenyi" <chenyi.qiang@intel.com>,
	"tglx@kernel.org" <tglx@kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>
Subject: Re: [PATCH 2/2] x86/tdx: Accept hotplugged memory before online
Date: Fri, 3 Apr 2026 19:41:38 +0000	[thread overview]
Message-ID: <f4639348586233245343005708372230f2d4a2cc.camel@intel.com> (raw)
In-Reply-To: <IA1PR11MB94952B22F6EB648ED7C1AE3CE75EA@IA1PR11MB9495.namprd11.prod.outlook.com>

On Fri, 2026-04-03 at 10:37 +0000, Reshetova, Elena wrote:
> > > > So the part about whether a triggered accept succeeds or returns an
> > > > already accepted error is already under the control of the host. > >
> > > > I.e., if we don't have the zeroing behavior, the host can already > >
> > > > cause the page to get zeroed. So I don't think anything is > >
> > > > regressed. Both come down to how careful the guest is about what it > >
> > > > accepts.
> > 
> > Yes, and my point is that we should not allow guest to freely double
> > accepting ever. 
> > For any use case that requires releasing memory and accepting it > back, it
> > should be explicit action by the guest to track that memory > has been
> > "released" (under correct and safe conditions) and then it > is ok to accept
> > it back (even if it doesnt mean physically accepting > it) and in this case
> > it is ok (and even strongly desired) to zero the > page to simulate the
> > normal accept behaviour. 

Hmm, it doesn't seem like you engaged with my point. Or at least I'm not
following what is exposed?

So I'm going to assume you agree that this procedure would not open up any
specific new capabilities for the host that don't exist today. And instead you
are just saying that the guest should have infrastructure to not double accept
memory in the first place.

But the problem here is not that the guest losing track of the accept state
actually. It is that the guest relies on the host to actually zap the S-EPT
before re-plugging memory at the same physical address space. So the guest is
tracking that the memory is released correctly. Better tracking will not help.
It relies on host behavior to not hit a double accept.

TDX connect will use this "unaccept" seamcall, so I asked Zhenzhong (Cced) how
much of what we need for that solution will just get added for TDX connect
anyway. It seems like we should make sure the same solution will work for both
SNP and TDX and keep the options open at this stage.

  reply	other threads:[~2026-04-03 19:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24 15:21 [PATCH 0/2] x86/tdx: Fix memory hotplug in TDX guests Marc-André Lureau
2026-03-24 15:21 ` [PATCH 1/2] x86/tdx: Handle TDG.MEM.PAGE.ACCEPT success-with-warning returns Marc-André Lureau
2026-03-24 22:02   ` Edgecombe, Rick P
2026-03-24 15:21 ` [PATCH 2/2] x86/tdx: Accept hotplugged memory before online Marc-André Lureau
2026-03-24 22:03   ` Edgecombe, Rick P
2026-03-25 10:29     ` Marc-André Lureau
2026-03-25 17:21       ` Edgecombe, Rick P
2026-03-26 18:25         ` Paolo Bonzini
2026-03-26 20:40           ` Edgecombe, Rick P
2026-03-30 12:29             ` Kiryl Shutsemau
2026-03-30 15:10             ` Pratik R. Sampat
2026-04-01 15:37               ` Edgecombe, Rick P
2026-04-01 15:49                 ` Edgecombe, Rick P
2026-04-02  8:18                 ` Reshetova, Elena
2026-04-02 17:06                   ` Edgecombe, Rick P
2026-04-03 10:37                     ` Reshetova, Elena
2026-04-03 19:41                       ` Edgecombe, Rick P [this message]
2026-04-08  8:22                         ` Reshetova, Elena
2026-04-08 19:55                           ` Pratik R. Sampat
2026-04-09  1:35                         ` Duan, Zhenzhong
2026-03-27  3:05       ` Chenyi Qiang
2026-03-27  8:49         ` David Hildenbrand (Arm)
2026-03-27  8:28   ` Yan Zhao
2026-03-30 12:17     ` Marc-André Lureau

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=f4639348586233245343005708372230f2d4a2cc.camel@intel.com \
    --to=rick.p.edgecombe@intel.com \
    --cc=bp@alien8.de \
    --cc=chenyi.qiang@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=elena.reshetova@intel.com \
    --cc=hpa@zytor.com \
    --cc=kas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcandre.lureau@redhat.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=prsampat@amd.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    --cc=zhenzhong.duan@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