public inbox for linux-coco@lists.linux.dev
 help / color / mirror / Atom feed
From: Kiryl Shutsemau <kas@kernel.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "pbonzini@redhat.com" <pbonzini@redhat.com>,
	 "x86@kernel.org" <x86@kernel.org>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	 "marcandre.lureau@redhat.com" <marcandre.lureau@redhat.com>,
	"hpa@zytor.com" <hpa@zytor.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>,
	"linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	 "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 2/2] x86/tdx: Accept hotplugged memory before online
Date: Mon, 30 Mar 2026 12:29:52 +0000	[thread overview]
Message-ID: <acprNlPP7J_ttMrz@thinkstation> (raw)
In-Reply-To: <424048885a01dcb6a7ef0256f0dc8a9adb546f22.camel@intel.com>

On Thu, Mar 26, 2026 at 08:40:06PM +0000, Edgecombe, Rick P wrote:
> Hi Paolo!
> 
> On Thu, 2026-03-26 at 19:25 +0100, Paolo Bonzini wrote:
> > > Another option could be to perform a TDG.MEM.PAGE.RELEASE TDCALL from
> > > the guest when it unplugs the memory, to put it in an unaccepted state.
> > > This would be more robust to buggy VMM behavior. But working around
> > > buggy VM behavior would need a high bar.
> > 
> > Wouldn't it actually be a very low bar? Just from these two paragraphs
> > of yours, it's clear that the line between buggy and malicious is
> > fine, in fact I think userspace should not care at all about removing
> > the memory. Only the guest cares about acceptance state.
> > 
> > Doing a RELEASE TDCALL seems more robust and not hard.
> 
> I mean I guess the contract is a bit fuzzy. The reason why I was thinking it was
> a host userspace bug is because the conventional bare metal behavior of
> unplugging memory should be that it is no longer accessible, right? If the guest
> could still use the unplugged memory, it could be surprising for userspace and
> the guest. Also, ideally I'd think the behavior wouldn't cover up guest bugs
> where it tried to keep using the memory. So forgetting about TDX, isn't it
> better behavior in general for unplugging memory, to actually pull it from the
> guest? Did I look at that wrong?
> 
> As for the bar to change the guest, I was first imagining it would be the size
> of the accept memory plumbing. Which was not a small effort and has had a steady
> stream of bugs to squash where the accept was missed.
> 
> But I didn't actually POC anything to check the scope so maybe that was a bit
> hasty. Should we do a POC? But considering the scope, I wonder if SNP has the
> same problem.

Doing RELEASE will be required with TDX Connect in the picture.
Otherwise userspace wouldn't be able to pull the memory out of TD.
So, let's do it and drop the first patch.

We can suggest that userspace actually remove the memory, but I don't
think it should be part of the contract. Userspace might have a reasons
to keep the memory around.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

  reply	other threads:[~2026-03-30 12:29 UTC|newest]

Thread overview: 14+ 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 [this message]
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=acprNlPP7J_ttMrz@thinkstation \
    --to=kas@kernel.org \
    --cc=bp@alien8.de \
    --cc=chenyi.qiang@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --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=rick.p.edgecombe@intel.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    /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